Re: Creating and App menu from Scratch
Re: Creating and App menu from Scratch
- Subject: Re: Creating and App menu from Scratch
- From: "Kyle Sluder" <email@hidden>
- Date: Mon, 14 Jul 2008 17:55:00 -0400
On Mon, Jul 14, 2008 at 3:06 PM, Bill Royds <email@hidden> wrote:
> Forms layout is not part of the "standard user experience" in general,
> although forms look and feel is.
Wrong. Otherwise the Apple HIG, the Windows interface guidelines, the
Gnome HIG, etc. all would lack sections on the positioning and spacing
of controls. The Apple HIG in particular is the odd one out because
it advocates center-aligning controls inside of windows.
> Are you saying that all Carbon applications
> are not Mac compatible since there is no conversion of Carbon nibs to Cocoa?
You're being a bit deceptive with "Mac compatible." I think you meant
that in the sense of "compatible with the expectations of a typical
Mac user." Applications written for OS 9 and ported straight to OS X
were horrible violators of the Aqua look and feel, so in one sense,
yes, they were incompatible with the environment.
> Software is also worse when the developer has to re-invent the wheel for
> each version.
Not necessarily worse. More expensive, yes. Perhaps to the point of
requiring additional team members, some of whom might not even be
programmers. But what's worth doing is worth doing right; those
people whose jobs have strange titles like "analyst" and "vice
president" have to make decisions about whether it's worth the extra
expense to invest in a new platform. To wit Gregory makes a very good
point; the cost of recreating the user interface elements according to
the expectations of the platform's user is negligible compared to the
loss in perceived value of an application that looks, feels, and
smells like it was machine-translated.
The most valuable part of almost any application from the author's
perspective is its business logic; the guts of the app that fulfill
the requirements. However, the user doesn't see any of that; the user
quite literally only sees the interface. I believe that investing the
additional money upfront in proper development for the Mac, rather
than treating it as a second-class citizen, will pay for itself in
perceived value and user satisfaction.
Before you consider me to be some dogmatic evangelist, I'm well aware
that there exist circumstances in which my argument is foolish.
Internal apps, for example, don't benefit nearly as much from polish
as shrinkwrap apps. This is especially true for scientific apps --
I've seen some horribe offenses against usability on Windows, Mac, and
Linux in math and engineering labs, but the software's utility lies in
such a niche, and interaction with the software is so minimal, that
investing in the user interface at the expense of the software's core
functionality would be unthinkable. But that argument is not
universal; the Adobe, Macromedia, and MS Office suites were for years
decried as examples of products whose designers cared not about the
users. The spin controls on the Adobe dialogs were awful, Office (and
Excel 2004 especially) looked like it was still designed for typefaces
half the size of the very readable 13pt Lucida Grande default, and
Macromedia changed its interface so many times that nobody knew if a
control still behaved the same way from version to version. And let's
all remember the fun of Java AWT UIs, and the abomination that is its
replacement Swing!
I suppose the question I should be asking you is, who is your
audience? What does your product do? Why do you want to
auto-generate your user interface in a serialized object graph form
from a textual template? That certainly wouldn't be my first choice.
If I were the president of an American auto manufacturer and decided
that I wanted to start selling cars in the UK, my first instinct
wouldn't be to design a mirror-image of one of my cars and fix what
broke. It would be to design a car from the ground up for my target
market that had the same soul as my original model, taking into
consideration the tastes of my audience in the process.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden