Fog Creek Software
Discussion Board

Why apps developed with MSFT tools have a poor UI

I am part of a group that develops biz apps using Delphi. We have all the visual components that are de facto standard in Delphi community (Express Gris, Virtual TreeView, etc) and with them we wipe up apps that users just love.
On the other hand another group doing similar apps using MSFT VC always comes up with clumsy apps, bad grids, missing type ahead functionality, basic tree views, and every time they decide to put some better looking UI components it results in having to add on the client some obscure OCX files that fail to register etc...

For me, best written UI app is Outlook, it has it all, complex data entry, grid views, sortitng, autoarchiving, intuitive UI with regards rules , etc.

So my questions is, why MSFT end products have always almost perfect UI, and at the same time development tools that MSFT produces do not allow the developers to even remotely mimic the functionality of Outlook, IE, Office
without adding extra components that increase administration workload on the client

My answer will be the touch of a genius in designing Delphi VCL, but I am not really sure

Tuesday, December 30, 2003

I think because creating components in Delphi is soooo much easier and better than in VB or VC++ there are many very advanced UI third party controls available. Also because developing these fancy third party grids/edits etc can be done many times faster in Delphi than ActiveX controls can be developed using VC++ (or VB if you want a crap result) they have more features and are more polished. These third party controls integrate much tighter with the delphi environment than alternative ActiveX style controls do in VB or VC++ the end result is a much nicer total package. Also adding third party controls to a project in Delphi does not have to be as painful as VB because there are no additional ActiveX controls or files that need to be distributed.

WinForms should close some of the ground on Delphi's component model, after all it was based on it.

Tuesday, December 30, 2003

Outlook has one neat feature that no one ever seems to use. Open up a new appointment and in the date field type something like 'next monday' or 'next month'. It will figure out the actual date and enter it for you.

Interaction Architect
Tuesday, December 30, 2003

I find out look complex, confusing, and lacking many
obvious tasks that would make my life easier.

son of parnas
Tuesday, December 30, 2003

Sorry, I have to disagree with you Seemore. 

Every single type of control used in Outlook is available for MSVC++ or VB.

Furthermore, most controls are compiled as Active X (OLE) objects.  One of the controls that you mentioned (Express Grid) is available as an OCX, and I can count about 10 TreeView controls out there that rival "Virtual Treeview".

Tuesday, December 30, 2003

One word: subclassing. In order to access most of the funcionality achieved by applications such as Outlook, using Microsoft tools you have to subclass some base class and add properties and methods for your own use. Delphi, on the other hand, have an event driven model that's much easier to extend, and is much more encapsulated (ie, you don't have to deal with queues, messages or other blunt objects.)

I guess this has changed with .NET, thought.

Leonardo Herrera
Tuesday, December 30, 2003

*  Recent Topics

*  Fog Creek Home