Re: Creating and App menu from Scratch
Re: Creating and App menu from Scratch
- Subject: Re: Creating and App menu from Scratch
- From: Bill Royds <email@hidden>
- Date: Mon, 14 Jul 2008 15:06:41 -0400
On 14-Jul-08, at 12:38 , Gregory Weston <email@hidden>wrote:
No he's not. Long-time Mac developers know quite well that by and
large Mac users are very averse to apps that simply don't fit. It's
not a question of arguments about "better" or "worse" (although such
arguments can certainly be had). The simple fact that an application
gratuitously deviates from the standard user experience is a killer
for almost any app that has competition. For what it's worth, Mac-
like applications on Windows are just as bad.
Forms layout is not part of the "standard user experience" in general,
although forms look and feel is. Are you saying that all Carbon
applications are not Mac compatible since there is no conversion of
Carbon nibs to Cocoa?
I'll give an example: Part of the user experience *for me* is that
Windows machines have 2-button mice and Macs have 1 or 3 buttons.
Obviously I'm not saying this is a general truth, but certainly the
vast majority of Windows installationshave 2 buttons, and the Macs
*I* use every day have the original mice or a 3-button replacement.
So here's the quirk:
When I sit down at a Mac with a 2-button mouse, if I right-click on
a file I expect to see a Windows context menu. I expect, for
example, to see a "Properties" item at the bottom of the menu, not a
"Get Info" near the top. The time it takes to recover from that
discrepancy is not just measurable; it's noticeable.
What has this go to do with the layout of a form?
Depending on the application, there
may have been a great deal of work in designing an interface specific
to a particular discipline. The layout may be a "standard" form
required by law or other convention. I am not suggesting that one
port
the code, just the forms and menu labels. Once they are ported to a
nib, they can be modified to better conform to Mac HI guidelines.
Kyle also didn't indicate that there was no possible way for a good
app to result from the use of such a tool. He just worries -
correctly in my opinion - that an awful lot of developers who would
use that tool wouldn't expend the resources to actually clean it up
after the fact. And when the app fails in that circumstance - not
if, but when - it's always cast as a failing of the Mac or its
market, rather than an acknowledgment that just possibly the app
itself was crap. Elitist as it may sound on first blush, the reality
is that software tends to be better when the developer is required
to think.
Software is also worse when the developer has to re-invent the wheel
for each version.
Bill Royds
_______________________________________________
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