I am by no means an UI Design expert, but I am just blogging my current thoughts on the topic. Also this is my personal opinion (based on the limited experience I have) and I might change my opinion with time as I get to see better frameworks.
There is this school of thought “automagically generating user interfaces based on a model” (either the Domain Model or the Data Model). The most prominent examples which I had seen include
- A Business Application Platform which supports building a domain model on the fly and provides UI Design capabilities (e.g. Microsoft Dynamics CRM, Sharepoint). The UI is modeled as a projection of the business domain. You get Forms to Create and Update domain entities, Lists to View and Delete domain entities.
- A Framework which supports UI scaffolding. This may not be as bad as the previous one, since there may not be a notion of permanence here. I see this as an anti-pattern even in the prototyping stage as it might limit/bias the UI Designer’s / Developer’s ideas. Examples include Ruby on Rails Scaffolding, Subsonic Scaffold control, ASP.NET Dynamic Data. I know very well that these are good frameworks and do not recommend anyone to use the generated UI in production applications. Also, I am talking only about the automagically generated UI.
A custom application where you do not have an UI Designer and the developer decides to structure the UI design around the domain model / data model. The UI will provide forms to Create and Update, Grids to View and Delete domain entities.
This CRUD of entities based UI Design can be considered a leaky abstraction where the domain model (or worse data model) has leaked into the UI. The Worst part is that the end users of the system are forced to wriggle around their daily tasks using the provided User Interface. So if we do not structure our UI as CRUD of entities what should we structure them around?
User Interfaces should be designed around the tasks which the Users perform day to day. For example a task might include displaying / editing information from multiple entities. The same data can be visualized differently in a way it is the most intuitive to the users. So if you are thinking of building a Framework to automatically generate CRUD User Interfaces around entities understand the limitations it will impose on the end users of the system.
One of the goals this year for me is to learn the Sharepoint platform. I’ll post my study notes as I go along. I am not a WSS guru, but you find this useful if you are new to Sharepoint like me 🙂
Windows SharePoint Services (referred to as WSS from here) is a Site provisioning engine. In plain English a platform which tries to simplify the act of creating web sites in a Web Farm environment.
Some notes from the Inside Microsoft Windows Sharepoint Services 3.0
“WSS was designed from the ground up to make the creation of Web sites faster and more cost effective. As a WSS developer, you will learn to develop components that others will use to create sites and workspaces.
At its core, WSS is a site provisioning engine. The architecture of WSS was specifically designed to operate in a Web farm environment. The act of provisioning (a fancy word for creating) a site in WSS can be accomplished by any member of the IT department in less than a minute by filling in the required information in a browser-based form and clicking the OK button. There’s no need for a database administrator to create a new database or any new tables. There’s no need for an ASP.NET developer to create a new ASP.NET Web site. There’s no need for a system administrator to copy any files or configure any IIS settings on the front-end Web server.”
“WSS is included as a part of the Windows Server 2003 operating system while MOSS is a separate product with its own SKU. You should think of WSS as the underlying platform and think of MOSS as a value-added set of components and services that has been built on top of this platform.”