Re: MFC & Guis


Daniel,

I think we're in agreement on all but one side point. I believe it *is* M$
responsibility to provide the purchasers of their development products with
anything and everything to make development effort on the target platforms
as productive as possible.

<IMO>
The fact that so many GUI wheels are reinvented by so many devs is an
indication that the vendor should focus more effort on building a greater
level of support in this area. That could be anything from better
documentation to better dev software support.
</IMO>

Thanks - this has been a good discussion. I'm always interested other's
perspectives on this kinda' stuff.


On Fri, 27 Jan 2006 10:58:37 GMT, Daniel James wrote:

> In article news:<1vhsi0ag1x56x$.8wtztiiscqfj.dlg@xxxxxxxxxx>, BobF wrote:
>> IMO, application development is still very much an art. We all see GUI's
>> that deviate from the "standard" - some we really like, some we hate.
>
> At the end of the day what matters most to the user is being able to use the
> software to get the job done. Users of Windows software form expectations
> about how an application will behave; they recognize the standard Windows
> controls and GUI metaphors like the menus and toolbars, and they learn that
> these are normally work in the same way in every application. This "if you've
> learnt one Windows app you can use them all" feature is very powerful -- and
> is one of the things that has contributed to Windows's widespread adoption.
>
> GUIs should be designed to take advantage of the existing familiarity users
> will have with the platform. Don't deviate from the platform's native "look
> and feel" or you'll make life harder for your users, make everything work the
> way they will expect. This is sometimes known as the "principle of least
> surprise".
>
> If you design an app with a GUI that deviates from the Windows norm for no
> good reason you will give your users an unnecessarily hard time when they try
> to learn to use your app. Worse: you will erode their grasp of the implicit
> "rules" of Windows GUI design that they have been learning from all other
> apps, and so /increase/ the effort they will have to expend to pick up other
> apps.
>
> This *is* evil, it *should* be argued against.
>
> Note that what I'm talking about here is essentially messing with the
> non-client areas of the windows -- the parts that Windows will draw for you
> in a standard way. Trying to change standard look and feel of those things is
> not only unnecessary expenditure of programmer effort, it violates the
> "principle of least surprise".
>
> None of this is to say that one should not be innovative in the way that
> information is presented and manipulated within the client areas. The
> Audacity example you linked elsewhere is a good case in point -- the
> non-client areas look like a Windows app (and, indeed, the nonclient areas of
> Audacity on linux or MacOS X have the proper appearance for those platforms)
> while the client areas exhibit behaviour specific to the application domain.
>
>> The bottom line is that "non-standard" GUI development isn't supported
>> directly by M$ tools or documentation, even though M$ developers obviously
>> put much effort into customizing M$ product GUI's.
>
> There are two issues here:
>
> - MS don't provide much in the way of tools or support for changing the
> non-client characteristics of application windows because it isn't desirable
> to encourage that this be done (I'm surprised they do it themselves, and that
> they even make it possible - it violates all good design guidelines).
>
> - MS don't provide much in the way of tools or support for implementing
> customized window clients because it's not their job. The client area is
> *your* responsibility, and only you can know what data you want to represent
> there, what representation of those data is going to be meaningful to the
> user, and what manipulations of those data your program is going to support.
>
>> This forces people to reach out for help.
>
> People are not being forced to ask for help to do things that most people
> will tell them they shouldn't be thinking of doing at all (or, at least, not
> without a very good and unusual reason).
>
>> In this particular case, the OP not only didn't [get] help, but was
>> also chastised for even thinking about trying to dress up an application.
>
> I may have stated my point a little too bluntly in my earlier posting here,
> and I'm sorry if any offence was caused. The OP's opening gambit "As we know
> MFC makes ugly GUIs" was a bit of a red rag, though ...
>
> MFC doesn't "make GUIs" at all (Windows makes the nonclient areas, and the
> application makes the client areas); these GUIs are neither more nor less
> "ugly" because of MFC (MFC just makes the programming easier - blame the
> Windows API not MFC if you don't like how it looks); "ugliness" is not really
> the isse (what matters is usability); and I don't consider the appearance of
> an MFC/Win32 app to be ugly anyway (unless running on XP in non-Classic
> mode).
>
>> Anyway, I'm not here to pick a fight. I just hate seeing people post
>> perfectly valid questions here, only to receive unjustified criticism in
>> return.
>
> I have no desire to fight, either. I may have overreatced to that question,
> but it did seem to me to be a cry for more of all that is worst in GUI
> programming.
>
> Cheers,
> Daniel.
.

Relevant Pages

  • Re: GUI programming, MFC and C#
    ... iterations of a product called Windows that didn't take off until Windows ... VB presented millions of folks with a way to develop GUI ... Microsoft added visual designers to C++ through Visual Studio using MFC. ... Depending on the size of your app, you could go one of two ways or ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: For the Windoze haters - VS2005
    ... first time produced a GUI that even the GUI developers were impressed ... by (of course not a fully functioning app), and I am not a GUI ... considering that probably 90% of my audience are windows users. ... supplied with the .net framework called NGEN that will compile it to a ...
    (sci.electronics.design)
  • Re: MFC & Guis
    ... Users of Windows software form expectations ... If you design an app with a GUI that deviates from the Windows norm for no ... while the client areas exhibit behaviour specific to the application domain. ...
    (microsoft.public.vc.mfc)
  • Re: Mac OS X and Linux
    ... degree of compatibility between the Mac gui and some other Linux one. ... Does this mean that most Windows apps are "statically" linked? ... > Assuming you have to release updates to a Windows or MacOS app ...
    (comp.os.linux.misc)
  • Re: Splash Screens , how could something so basic still be hard?
    ... You say that there "is no message pump to allow for further GUI ... Note that by "there is no message pump", I mean that because of the way the code is written, no message pump is working while the "splash screen" is displayed. ... In a normal Forms app, there would be a message pump loop, and there's no reason to believe that in those examples, one doesn't exist. ... The same technique is possible in Windows, ...
    (microsoft.public.dotnet.languages.csharp)