"untitled" vs "Untitled"
-
Apple's guidelines state that new documents should be named
"untitled", but NSDocument uses the capitalized "Untitled". Has
anyone made a workaround for this, before I start on it myself?
--
David Catmull
<uncommon...>
http://www.uncommonplace.com/ -
To my knowledge, there is no method in NSDocument or
NSWindowController to set the title of a new document.
A workaround might be to use NSDocument's -window when a new document
is created and then with that window use NSWindow's setTitle. You
would have to keep track of the number of new documents that have
been created, and the stick that number to the end of the title
I know the guidelines say new documents should be named "untitled",
but I have never seen an application that actually does this. Since
users are used to seeing an uppercase letter, it could become confusing.
Adam Leonard
On Jul 9, 2005, at 1:08 PM, David Catmull wrote:
> Apple's guidelines state that new documents should be named
> "untitled", but NSDocument uses the capitalized "Untitled". Has
> anyone made a workaround for this, before I start on it myself?
>
> --
> David Catmull
> <uncommon...>
> http://www.uncommonplace.com/
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<web...>
>
> This email sent to <web...>
>
>
-
> I know the guidelines say new documents should be named "untitled",
> but I have never seen an application that actually does this.
Pages uses "untitled"
Adobe GoLive CS uses "untitled"
BBEdit Lite uses "untitled"
Carbonized apps from old classical apps by developers who knew what
they were doing use "untitled"
A lot of new apps use NSDocument, which is why so many apps are wrong.
Apple has known about this bug for some time now. Apple developers
said it would be fixed... but it hasn't yet, which is saddening for me.
But this is already off-topic and should be on HIT-Dev, really. -
"Untitled" is perfectly fine, and the HI guidelines need to be
addressed to clarify this.
Ali
Begin forwarded message:
> From: David Catmull <uncommon...>
> Date: July 9, 2005 13:08:34 PDT
> To: <cocoa-dev...>
> Subject: "untitled" vs "Untitled"
>
>
> Apple's guidelines state that new documents should be named
> "untitled", but NSDocument uses the capitalized "Untitled". Has
> anyone made a workaround for this, before I start on it myself?
>
> --
> David Catmull
> <uncommon...>
> http://www.uncommonplace.com/
-
> "Untitled" is perfectly fine, and the HI guidelines need to be
> addressed to clarify this.
> Ali
No, it's not "perfectly fine". If you're using NSDocument, then you
can just ignore it for now and let Apple fix it (which is one way of
saying "it's perfectly fine," but developers should be aware of the
subtitles in the reasoning behind this statement of "perfectly fine";
that is, that's because once apple fixes it, it will instantly become
correct.)
The HI guidelines are already quite clear:
"Name a new document window “untitled”; leaving it lowercase makes it
more obvious that the
window doesn’t have a name and encourages people to save the
document. If the user chooses New
again before saving the first untitled window, name the second window
“untitled 2,” and so on. Add
numbers to window titles only when there is more than one open
untitled window. Don’t put a “1”
on the first untitled window, even after the user opens other new
windows." (Page 181)
I apologize for continuing this off-topic thread. -
Am 10.07.2005 um 01:05 Uhr schrieb Ali Ozer:
> "Untitled" is perfectly fine, and the HI guidelines need to be
> addressed to clarify this.
I disagree. Fix NSDocument instead of changing the guidelines.
Andreas -
On Jul 9, 2005, at 5:55 PM, Andreas Mayer wrote:
>> "Untitled" is perfectly fine, and the HI guidelines need to be
>> addressed to clarify this.
>>
>
> I disagree. Fix NSDocument instead of changing the guidelines.
Yup. Changing the guidelines to be consistent with the existing
engineering seems a backwards way to do things.
_murat -
Lowercasing a name is a technique that doesn't apply in all
languages; in addition, these days we have the proxy icon, which more
clearly states whether the document has been saved on disk, in
addition to the dot in the close box, which indicates whether it is
currently saved or not. Neither of these techniques was around when
this guideline was written up. But these days the lowercasing of
"untitled" is unnecessary in addition to being incomplete and unsightly.
Ali
Begin forwarded message:
> From: "Brian K." <codesamurai...>
> Date: July 9, 2005 16:36:47 PDT
> To: Ali Ozer <aozer...>
> Cc: <cocoa-dev...>
> Subject: Re: "untitled" vs "Untitled"
>
>
>> "Untitled" is perfectly fine, and the HI guidelines need to be
>> addressed to clarify this.
>> Ali
>>
>
> No, it's not "perfectly fine". If you're using NSDocument, then
> you can just ignore it for now and let Apple fix it (which is one
> way of saying "it's perfectly fine," but developers should be aware
> of the subtitles in the reasoning behind this statement of
> "perfectly fine"; that is, that's because once apple fixes it, it
> will instantly become correct.)
>
> The HI guidelines are already quite clear:
> "Name a new document window “untitled”; leaving it lowercase makes
> it more obvious that the
> window doesn’t have a name and encourages people to save the
> document. If the user chooses New
> again before saving the first untitled window, name the second
> window “untitled 2,” and so on. Add
> numbers to window titles only when there is more than one open
> untitled window. Don’t put a “1”
> on the first untitled window, even after the user opens other new
> windows." (Page 181)
>
> I apologize for continuing this off-topic thread.
>
-
On Jul 10, 2005, at 2:58 AM, Ali Ozer wrote:
> Lowercasing a name is a technique that doesn't apply in all languages;
It doesn't have to apply to all languages. I don't expect it to be
done in Japanese. It can be done for the English localization, and
probably a few latin based languages.
Also, in the latest HIG text, there's also that big figure on page
182 that takes up half the page. In that figure is a screenshot of
an example of proper untitled window name (i.e. "untitled") that has
a "Do this" checkmark next to it, along with four examples of what
NOT to do with red "Do NOT do this" symbols next to them; included in
this bunch of what NOT to do is an example of "Untitled".
> in addition, these days we have the proxy icon, which more clearly
> states whether the document has been saved on disk,
Yes, but it's not all that obvious in comparison to the name itself
indicating such.
> in addition to the dot in the close box, which indicates whether it
> is currently saved or not.
Which is a good supplemental feature, but it is no excuse for
removing an excellent guideline (which has really good psychological
roots in its reasoning).
> Neither of these techniques was around when this guideline was
> written up.
True, but that doesn't mean it's still not a good guideline. Change
for change's sake is not a reason.
> But these days the lowercasing of "untitled" is unnecessary
I beg to differ. A lot of things that might not be considered
"necessary" really are necessary for the elegance---adding finesse to
the subtle details of the work environment. In my experience, a lot
of programmers miss this concept, but the great ones don't. If you
start ignoring the niceties of the details, then you start getting
Windows and Linux GUIs.
> in addition to being incomplete and unsightly.
How is it incomplete? And it's not unsightly, it's just SUPPOSED to
draw attention to the fact that it's not saved. The people who wrote
up the core guidelines long ago really did know what they were
doing. I'd hate to see this good thing messed up. I see it all the
time---the new engineers who do not have the upmost intimate
knowledge of the design, destroy well thought-out and excellent
design aspects.
I further quote from Apple texts:
"Never capitalize the word 'untitled' in a new window title. It
makes the window look like it has a name and discourages people from
saving the document with a meaningful name. Don't number the first
new window with the numerical one. Usually people open only one
window, use it, save and name it, and then go on with other work. In
this case, numbering one instance of a window doesn't make sense and
is distracting. Also, don't add punctuation of any kind to untitled
window titles. Figure 5-11 shows several examples of window titles
that use naming techniques you should avoid; it includes an example
of the right way to title a window."
I agree with these guidelines wholeheartedly. -
On Jul 9, 2005, at 11:58 PM, Ali Ozer wrote:
> Lowercasing a name is a technique that doesn't apply in all
> languages; in addition, these days we have the proxy icon, which
> more clearly states whether the document has been saved on disk, in
> addition to the dot in the close box, which indicates whether it is
> currently saved or not. Neither of these techniques was around
> when this guideline was written up. But these days the lowercasing
> of "untitled" is unnecessary in addition to being incomplete and
> unsightly.
So it's true then? Engineering has taken over user experience/
interface design at Apple these days? Perhaps that explains things
like cmd-+ requiring that I hold down the cmd key, the plus key, and
the shift key (on US keyboards at least)...
At least Safari and Mail handle this correctly.
In any case, I believe that common title capitalization conventions
(e.g. as in the Chicago Manual of Style <http://
www.chicagomanualofstyle.org>) are behind this particular guideline.
That's why a capitalized "Untitled" looks like a title, whereas
"untitled" does not. In English anyway. Turkish too, I might add. ;)
_murat -
> So it's true then? Engineering has taken over user experience/
> interface design at Apple these days? [...]
>
> In any case, I believe that common title capitalization conventions
> (e.g. as in the Chicago Manual of Style <http://
> www.chicagomanualofstyle.org>) are behind this particular
> guideline. That's why a capitalized "Untitled" looks like a title,
> whereas "untitled" does not. In English anyway. Turkish too, I
> might add. ;)
Exactly! ^_^
Alright, I'm going to point out the elegant simplicity of this semi-
verbosely:
If something is titled, title case is appropriate for the text,
because it is titled.
If something is untitled, then it is not titled; title case is
inappropriate as it is not a title and therefore should not be in
case which belongs to and is intended for titling.
That's it. Why should an untitled thing use title case? It
shouldn't---it's *untitled* for goodness sakes! The pseudo-title of
"untitled" just reinforces this on multiple levels.
-----------------------------------------------------------
Now, anyone wants to read any more commentary (doubtful)...
Ali may know "NeXT," and I respect that, but the Mac is a different
animal. It is now a "Mac OS" after all, but that's really not my
point. Does that mean every aspect of the classical Mac OS?
No...hardly. What it does mean is that it should share the best of
both. In this case, this is an example of a "best" that existed and
still exists Mac side, as far as I'm concerned.
Both operating environments had excellent design, behavior, workflow
aspects to contribute to each other; all of which should culminate in
Mac OS X.
It's really about looking at the design itself and its PURPOSE. By
comparison to the other aspects of both operating environments, this
is really one design detail that fits very well and WITHOUT ANY
design conflict in the resulting OS, as far as I'm concerned.
This is not just a superficial appearance issue, this is a core
humane interface issue, and I don't think I need to address how
humans communicate, all the details and psychological implications of
communication within the modern human population for various
languages, the differing and similar aspects in respect to this in
regions upon this planet, and how localizations in computer software
are specifically inclined to allow for this kind of catering for detail.
Signing off on this way-off-topic thread (and refusing to reply to
the mailing list for this thread after this message),
Brian -
> If something is titled, title case is appropriate for the text,
> because it is titled.
It's really worse than that. Unless there were a good solid affirmative
reason for the change, then it was incorrect to introduce this
inconsistency. IOW, you don't even need a reason for "untitled" in order to
call this NSDocument behavior a bug, all you need is a lack of a reason for
"Untitled".
--
Scott Ribe
<scott_ribe...>
http://www.killerbytes.com/
(303) 665-7007 voice -
Am 10.07.2005 um 09:28 Uhr schrieb Brian K.:
> I agree with these guidelines wholeheartedly.
<aol>me too!</aol> :)
Andreas -
I don't really have an opinion one way or the other on whether
"untitled" should be capitalized or not on a new document window, but
a couple of things have been said in pursuit of that topic on which I
do have opinions.
On Jul 10, 2005, at 6:56 AM, Brian K. wrote:
>> in addition, these days we have the proxy icon, which more clearly
>> states whether the document has been saved on disk,
>
> Yes, but it's not all that obvious in comparison to the name itself
> indicating such.
I've been a Mac user for twenty years. I never noticed that new
windows had lowercased "untitled" for the name. It certainly never
occurred to me that I could or should look at the case of the window
name as an indicator of whether it had ever been saved or not.
>> in addition to the dot in the close box, which indicates whether it
>> is currently saved or not.
>
> Which is a good supplemental feature, but it is no excuse for
> removing an excellent guideline (which has really good psychological
> roots in its reasoning).
>
>> Neither of these techniques was around when this guideline was
>> written up.
>
> True, but that doesn't mean it's still not a good guideline. Change
> for change's sake is not a reason.
Consider carefully these last two bits. I agree that change for the
sake of change is not a virtue, but persistence for the sake of
persistence isn't either. You go on to say...
> The people who wrote up the core guidelines long ago really did know
> what they were doing.
... and I can't help but notice the use of past tense. "Wrote" ...
"long ago" ... "did know." Granted that gratuitous change is a bad
thing, where's the evidence that what those people wrote "long ago"
remains correct? The fundamental rule of interface design, as far as
I know, is to (try to) do what the user expects. User expectations
change slowly (usually) but continuously. If in the tim since the
guideline (and note that the word is guideline, not rule) was written
user expectations have changed then changing the guideline may not,
in fact, be gratuitous.
G -
> Alright, I'm going to point out the elegant simplicity of this semi-
> verbosely:
>
> If something is titled, title case is appropriate for the text,
> because it is titled.
> If something is untitled, then it is not titled; title case is
> inappropriate as it is not a title and therefore should not be in
> case which belongs to and is intended for titling.
>
> That's it. Why should an untitled thing use title case? It
> shouldn't---it's *untitled* for goodness sakes! The pseudo-title
> of "untitled" just reinforces this on multiple levels.
This is elegant but rather an English-centric argument.
- As I said earlier, to some international users there won't be a
difference at all.
- And even in Roman scripts, some users might very well use lower
case to title their document names even when saved.
So trying to represent untitledness via lack of title-casing is not
always necessarily a clue and is not global. So we have proxy icons
to more exactly represent untitledness.
Also, no user I've talked to (and had talked to, even years ago) was
aware that the lower case in "untitled" was there to convey some
information. Now, this is information that is rather important, so
if it needs to be communicated, then it should be communicated in a
more explicit way, and not just for speakers whose languages use
alphabets with case variations.
There are other ways to do this:
- If the document is untitled, why have a title? Leave the title
blank. (Clearly a bit wacky and ugly)
- Make the title a different color, or font style, or use some other
indication which a titled document would never use. (Under
discussion with HI)
At this point use of "untitled" vs "Untitled" is more of an aesthetic
question, and (to bring the discussion back to Cocoa-land) NSDocument
uses a naming convention with capitalization familiar to users of
Adobe and Microsoft apps. By sticking with NSDocument's default
behavior, your apps will have leverage of any change that might
happen in the guidelines and frameworks. But if you want to use
"untitled," you are free to do so, since I believe the hooks exist in
NSDocument.
Ali -
On Jul 10, 2005, at 8:44 AM, Ali Ozer wrote:
> At this point use of "untitled" vs "Untitled" is more of an
> aesthetic question, and (to bring the discussion back to Cocoa-
> land) NSDocument uses a naming convention with capitalization
> familiar to users of Adobe and Microsoft apps. By sticking with
> NSDocument's default behavior, your apps will have leverage of any
> change that might happen in the guidelines and frameworks. But if
> you want to use "untitled," you are free to do so, since I believe
> the hooks exist in NSDocument.
Maybe Engineering disagrees internally with the HIG in some places.
That's natural. But until the HIG is actually changed, isn't it
Engineering's job to follow it to the letter? I don't agree with the
sentiment that "well, we thought this part of the HIG could use some
work, so we ignored it and did something a little different instead."
It's bad enough when third parties do it, but when the application
frameworks do it, that can cause serious inconsistency. I mean,
Carbon and Cocoa are on parallel development tracks with different
developers, but they're both trying to conform to the same HIG,
right? This makes inconsistencies stand out even more, because every
time one team deviates from the HIG, that's one more thing users can
notice and say "oh look, Carbon apps do this wrong" or "Cocoa apps
don't do such-and-such like a standard Mac app does." We've all heard
it before, right? :)
Actually, this kind of reminds me of how many controls still behave
differently between Carbon and Cocoa--just as one example that I have
handy, try holding the mouse button down and scrubbing over the tabs
in a tab control. In Carbon it behaves like a button (only the tab
you originally clicked will receive clicks) but in Cocoa it lets you
scrub between all the tabs with the button held down. (rdar://
2778946 ... filed in September 2001, still unfixed!) I don't have the
HIG in front of me so I am not certain which way is more "correct,"
but I suspect the HIG doesn't leave the question unanswered. However,
it seems like sometimes Engineering implements what they think the
standard SHOULD be, not what it says. -
On Jul 10, 2005, at 11:32 AM, John Stiles wrote:
> Actually, this kind of reminds me of how many controls still behave
> differently between Carbon and Cocoa--just as one example that I
> have handy, try holding the mouse button down and scrubbing over
> the tabs in a tab control. In Carbon it behaves like a button (only
> the tab you originally clicked will receive clicks) but in Cocoa it
> lets you scrub between all the tabs with the button held down.
> (rdar://2778946 ... filed in September 2001, still unfixed!) I
> don't have the HIG in front of me so I am not certain which way is
> more "correct," but I suspect the HIG doesn't leave the question
> unanswered.
The thing that bothers Cocoa engineers (and those with a NeXTSTEP
background) is the assumption that the old Mac way is the right way
to do things. This is the assumption that if Cocoa does it
differently then its a bug in Cocoa, not in Carbon.
In some ways the NeXTSTEP user interface was better than the Mac user
interface. For example, NeXTSTEP did a much better job handling
multiple applications and multiple windows (the dock, open file icons
along the bottom, ways to reorder windows, actually showing the
window when it was dragged, etc). NeXTSTEP also eschewed modal
dialogs and used modeless inspectors, which are quite common on OS X
today. NeXTSTEP apps tended have a lot more WYSIWYG aspects - such as
when you dragged a box in a graphical editor, you actually saw the
box move, not a dotted outline. In general the NeXTSTEP interface was
a lot more liberal, a lot more freeing than the Mac interface. Some
of that has carried forth in Cocoa applications. For example, Cocoa
apps tend to let you copy value text fields, even the text in the
About panel can be copied. The Finder, however, still prevents
copying value text fields in the inspectors. The user has to manually
transcribe that information if they need it elsewhere.
So anyway that's the thing with Cocoa engineers. Some Cocoa things
are better, some old Mac things are better. -
To bring this back on topic: I agree with the guideline as it
currently stands and I am interested in having my Cocoa application
follow it, regardless of whether other people agree with this
guideline or what Apple needs to fix or whether capitalization
matters in other languages. The fact that it matters in one language
- especially a very popular one - is enough for me.
I'm a little surprised that no one else has tackled this. It seems to
me from the documentation that the way to go is to override
NSDocument's -displayName method. If anyone knows better, please let
me know. Once I get it working I'll make the code available.
--
David Catmull
<uncommon...>
http://www.uncommonplace.com/ -
On Jul 10, 2005, at 11:55 AM, Carlos Salinas wrote:
> On Jul 10, 2005, at 11:32 AM, John Stiles wrote:
>
>> Actually, this kind of reminds me of how many controls still
>> behave differently between Carbon and Cocoa--just as one example
>> that I have handy, try holding the mouse button down and scrubbing
>> over the tabs in a tab control. In Carbon it behaves like a button
>> (only the tab you originally clicked will receive clicks) but in
>> Cocoa it lets you scrub between all the tabs with the button held
>> down. (rdar://2778946 ... filed in September 2001, still unfixed!)
>> I don't have the HIG in front of me so I am not certain which way
>> is more "correct," but I suspect the HIG doesn't leave the
>> question unanswered.
>>
>
> The thing that bothers Cocoa engineers (and those with a NeXTSTEP
> background) is the assumption that the old Mac way is the right way
> to do things. This is the assumption that if Cocoa does it
> differently then its a bug in Cocoa, not in Carbon.
>
> In some ways the NeXTSTEP user interface was better than the Mac
> user interface. For example, NeXTSTEP did a much better job
> handling multiple applications and multiple windows (the dock, open
> file icons along the bottom, ways to reorder windows, actually
> showing the window when it was dragged, etc). NeXTSTEP also
> eschewed modal dialogs and used modeless inspectors, which are
> quite common on OS X today. NeXTSTEP apps tended have a lot more
> WYSIWYG aspects - such as when you dragged a box in a graphical
> editor, you actually saw the box move, not a dotted outline. In
> general the NeXTSTEP interface was a lot more liberal, a lot more
> freeing than the Mac interface. Some of that has carried forth in
> Cocoa applications. For example, Cocoa apps tend to let you copy
> value text fields, even the text in the About panel can be copied.
> The Finder, however, still prevents copying value text fields in
> the inspectors. The user has to manually transcribe that
> information if they need it elsewhere.
>
> So anyway that's the thing with Cocoa engineers. Some Cocoa things
> are better, some old Mac things are better.
I think you're missing my entire point.
The goal of an engineer should not be to implement what they
personally think is the "best." The goal should be to implement the
HIG perfectly.
If the HIG is sub-standard, then talk to the authors and get it
fixed! Obviously there have been a lot of NeXT-themed ideas added to
the HIG already. Once the HIG is fixed, everyone benefits--Carbon,
Cocoa, and third-party developers. And if the HIG authors don't like
your idea, the engineers need to respect their judgement. The HIG is
what makes a Mac a Mac. (Obviously it's not the CPU :P ) -
On Jul 10, 2005, at 8:44 AM, Ali Ozer wrote:
>> If something is titled, title case is appropriate for the text,
>> because it is titled.
>> If something is untitled, then it is not titled; title case is
>> inappropriate as it is not a title and therefore should not be in
>> case which belongs to and is intended for titling.
>>
>> That's it. Why should an untitled thing use title case? It
>> shouldn't---it's *untitled* for goodness sakes! The pseudo-title
>> of "untitled" just reinforces this on multiple levels.
>
> This is elegant but rather an English-centric argument.
No, it's a "many, many language"-centric argument. Many languages
(and languages that the majority if your users use) have title
capitalization conventions, and even if the details of the
conventions vary from locale to locale, most of them capitalize the
first non preposition word.
> - As I said earlier, to some international users there won't be a
> difference at all.
So no problem either way, right?
> - And even in Roman scripts, some users might very well use lower
> case to title their document names even when saved.
Fine, it is after all their choice.
> So trying to represent untitledness via lack of title-casing is not
> always necessarily a clue and is not global. So we have proxy
> icons to more exactly represent untitledness.
I think perhaps there is a misunderstanding here. It's not a matter
of trying to convey that the document has never been saved (as you
note, there are superior ways to do that already), it's a matter of
following the typographic conventions for the language you are
running under. Attention to these kinds of details always set the the
Mac UI apart from other UIs, and is still something that it mostly
excels at. It would be a shame to let it erode away...
> NSDocument uses a naming convention with capitalization familiar to
> users of Adobe and Microsoft apps.
This smells like a post-hoc rationalization. What next, the dreaded
"Yes" "No" dialog box? Has user experience/interface design has been
turned over to Microsoft and Adobe?
(I'll just note that Adobe's Photoshop lets me use cmd-+ to zoom in
without requiring that the shift key be held down. It'd be nice if I
didn't have to jump through hoops to do the same thing with Cocoa).
_murat -
Please keep this relevant to Cocoa. Discussion of how to set an
NSDocument's title is relevant, discussion of the relative titling
schemes in general is not.
mmalc -
On Jul 10, 2005, at 3:02 PM, John Stiles wrote:
> Maybe Engineering disagrees internally with the HIG in some places.
> That's natural. But until the HIG is actually changed, isn't it
> Engineering's job to follow it to the letter?
Well, actually, no. It's not. Guidelines are not written to be
followed to the letter. They're intended to convey what should be a
standard gestalt of behavior and appearance unless there's a
compelling reason to deviate. It's been a while since I've read the
HIG but that distinction used to be made quite clearly in them. Apple
has been providing applications that fail to adhere to the HIG "to
the letter" since January 1984. -
On Jul 10, 2005, at 12:52 PM, mmalcolm crawford wrote:
> Please keep this relevant to Cocoa. Discussion of how to set an
> NSDocument's title is relevant, discussion of the relative titling
> schemes in general is not.
Here's a HIG (and human) compliant override for NSDocument's
displayName method. I haven't exhaustively tested it, but it seems to
work for the languages I've tried.
- (NSString *)displayName
{
NSString* displayName = [super displayName];
// Determine if this document was never saved.
// We do this by checking if the document has a file path. This is
// complicated (slightly) by the fact that NSDocument's fileURL
method
// is new in Tiger, and NSDocument's filePath is method
// is deprecated in Tiger.
BOOL neverSaved = NO;
if ([self methodForSelector:@selector(fileURL)])
{
neverSaved = [self fileURL] == nil;
}
else
{
neverSaved = [self fileName] == nil;
}
if (neverSaved)
{
// Lowercase the displayName so that, for example,
// "Untitled 4" becomes "untitled 4".
displayName = [displayName lowercaseString];
}
return displayName;
}
_murat -
On Jul 10, 2005, at 2:52 PM, Gregory Weston wrote:
> On Jul 10, 2005, at 3:02 PM, John Stiles wrote:
>
>
>> Maybe Engineering disagrees internally with the HIG in some places.
>> That's natural. But until the HIG is actually changed, isn't it
>> Engineering's job to follow it to the letter?
>>
>
> Well, actually, no. It's not. Guidelines are not written to be
> followed to the letter. They're intended to convey what should be a
> standard gestalt of behavior and appearance unless there's a
> compelling reason to deviate. It's been a while since I've read the
> HIG but that distinction used to be made quite clearly in them.
> Apple has been providing applications that fail to adhere to the
> HIG "to the letter" since January 1984.
In the context I was writing my statement, "engineering" meant "the
developers at Apple who are writing Carbon and Cocoa." Applications
may decide to deviate from the HIG in cases where it makes sense,
sure. But it's hard to come up with a case where the framework itself
(Cocoa) should violate the rules that specify how the framework
should operate (the HIG). And in this case it's very clear that
there's no compelling justification to violate the HIG, except that
some engineers think it's aesthetically displeasing. Frankly, that's
not a good justification for violating any standard IMO. -
On 11.07.2005, at 00:43, John Stiles wrote:
> In the context I was writing my statement, "engineering" meant "the
> developers at Apple who are writing Carbon and Cocoa." Applications
> may decide to deviate from the HIG in cases where it makes sense,
> sure. But it's hard to come up with a case where the framework
> itself (Cocoa) should violate the rules that specify how the
> framework should operate (the HIG). And in this case it's very
> clear that there's no compelling justification to violate the HIG,
> except that some engineers think it's aesthetically displeasing.
> Frankly, that's not a good justification for violating any standard
> IMO.
Well as the name HIG says: Its a guideline - NOT a law. No one is
forced to do it that way and nobody can violate a guideline. I'm even
thinking of changing "untitled" to "unnamed" in my apps, as a user
names a file/document and doesn't title it. But perhaps thats
different in american english.
And I hate to say it but sometimes an engineer is more competent in
normal app-usage than a designer or psychologist who writes the
guidelines. I would always break guidelines if they don't make sense
for my apps, as is Apple... -
On Jul 10, 2005, at 21:52 , mmalcolm crawford wrote:
> Please keep this relevant to Cocoa. Discussion of how to set an
> NSDocument's title is relevant, discussion of the relative titling
> schemes in general is not.
I guess this is the point where I hope for mmalc's forgiveness and
give a shameless plug for
http://groups.yahoo.com/group/mac-gui-dev/
The Mac-GUI-Dev mailing list, which was created exactly to be a place
for discussions like this that don't belong on Cocoa-Dev. Feel free
to continue there.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de -
On Jul 10, 2005, at 5:06 PM, Jan Neumüller wrote:
> On 11.07.2005, at 00:43, John Stiles wrote:
>
>> In the context I was writing my statement, "engineering" meant
>> "the developers at Apple who are writing Carbon and Cocoa."
>> Applications may decide to deviate from the HIG in cases where it
>> makes sense, sure. But it's hard to come up with a case where the
>> framework itself (Cocoa) should violate the rules that specify how
>> the framework should operate (the HIG). And in this case it's very
>> clear that there's no compelling justification to violate the HIG,
>> except that some engineers think it's aesthetically displeasing.
>> Frankly, that's not a good justification for violating any
>> standard IMO.
>>
>
> Well as the name HIG says: Its a guideline - NOT a law. No one is
> forced to do it that way and nobody can violate a guideline. I'm
> even thinking of changing "untitled" to "unnamed" in my apps, as a
> user names a file/document and doesn't title it. But perhaps thats
> different in american english.
>
> And I hate to say it but sometimes an engineer is more competent in
> normal app-usage than a designer or psychologist who writes the
> guidelines. I would always break guidelines if they don't make
> sense for my apps, as is Apple...
Remember, Apple itself writes the HIG. If, in the development of the
Carbon or Cocoa frameworks, a framework engineer finds a portion of
the HIG which is just worthless or unimplementable or confusing, they
can walk over to the office of the guy who wrote that page of the HIG
and discuss how to amend it. Then they can change the HIG (or
alternatively, the engineer might learn why the HIG was correct to
begin with).
IMO, most developers--even for the Mac!---have very little aesthetic
sense and can't explain what makes a user interface "good." (Windows
quite obviously has many pieces of UI which were designed by
programmers, and it shows.) I think it's a bad idea to let engineers
arbitrarily override the guidelines, since the people who wrote the
guidelines tend to have thought things through quite well. I say this
with years of experience following the HIG... they've managed to
maintain a consistent Mac feel for many years, even across the 9->X
transition, with painstaking attention to very minor issues that most
of us would take for granted.
And in the (very rare) cases where the HIG isn't fully baked, and the
framework engineer feels that it cannot be implemented as written (or
would make a poor UI), I think they need to make sure the HIG is
amended for everyone's benefit. -
On Jul 10, 2005, at 6:14 PM, Uli Kusterer wrote:
> I guess this is the point where I hope for mmalc's forgiveness and
> give a shameless plug for
> http://groups.yahoo.com/group/mac-gui-dev/
>
Pointing an appropriate forum to take the thread is welcome. Please
take it there.
mmalc -
On Jul 10, 2005, at 7:32 PM, mmalcolm crawford wrote:
>
> On Jul 10, 2005, at 6:14 PM, Uli Kusterer wrote:
>
>
>> I guess this is the point where I hope for mmalc's forgiveness
>> and give a shameless plug for
>> http://groups.yahoo.com/group/mac-gui-dev/
>>
>>
>
> Pointing an appropriate forum to take the thread is welcome.
> Please take it there.
>
> mmalc
Thank you, this discussion has gotten very tedious.
Phil -
I wrote earlier:
Please keep this relevant to Cocoa. Discussion of how to set an
NSDocument's title is relevant, discussion of the relative titling
schemes in general is not.
murat has provided a solution to the relevant issue. Subsequent
discussion is not on-topic. Please take further discussion
elsewhere, such as <http://groups.yahoo.com/group/mac-gui-dev/>.
mmalc -
I think the bigger issue is that when you make a new project via
xcode's project templates it should follow the HIG. Right now if you
make an NSDocument application via xcode, it does *not* follow the
HIG. And that needs to be fixed.
The case was similar before when making a new application would have
the Find Backwards command key as Command D instead of Command Shift
G. That was fixed a while ago.
And the HIG can't be "fixed" to say that the proper was is "Untitled"
because that makes almost every single Carbon application that does
follow the HIG wrong.
BTW, making a new folder in the Finder makes the folder name "untitled folder".
Someone mentioned that some old school mac users consider everything
that NeXT did wrong, when this is a case of a someone thinking the
carbon way is inherently wrong.
Ack, at 7/10/05, John Stiles said:
> And in the (very rare) cases where the HIG isn't fully baked, and
> the framework engineer feels that it cannot be implemented as
> written (or would make a poor UI), I think they need to make sure
> the HIG is amended for everyone's benefit.
--
Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People -
On Jul 10, 2005, at 4:49 PM, m <m0987...> wrote:
> Here's a HIG (and human) compliant override for NSDocument's
> displayName method. I haven't exhaustively tested it, but it seems to
> work for the languages I've tried.
Thanks! Now I can ignore the rest of this thread :)
--
David Catmull
<uncommon...>
http://www.uncommonplace.com/ -
For the archives:
I had posted an override for NSDocument's displayName method that
produces HIG compliant results for untitled documents. It's been
pointed out to me that all nouns are capitalized in German (and only
German apparently), despite efforts at reform <http://
en.wikipedia.org/wiki/German_spelling_reform>, so I modified the code
to account for this.
I make no claim that it will produce universally correct results, but
for localizations that are available in AppKit (Danish, Dutch,
English, Finnish, French, German, Italian, Japanese, Korean,
Norwegian, Portuguese, Spanish, Swedish, and Chinese), it appears to
work fine.
- (NSString *)displayName
{
NSString* displayName = [super displayName];
// Determine if this document was never saved.
// We do this by checking if the document has a file path. This is
// complicated (slightly) by the fact that NSDocument's fileURL
method
// is new in Tiger, and NSDocument's filePath is dperectaed in
Tiger.
BOOL neverSaved = NO;
if ([self methodForSelector:@selector(fileURL)])
{
neverSaved = [self fileURL] == nil;
}
else
{
neverSaved = [self fileName] == nil;
}
if (neverSaved)
{
// Special case for German.
// German is the only language in the world that
capitalizes
// all nouns, so our strategy of lowercasing would
produce the
// wrong result.
NSDictionary* userDefaults = [[NSUserDefaults
standardUserDefaults] dictionaryRepresentation];
NSArray* myLocalizations = [[NSBundle mainBundle]
localizations];
NSArray* preferredLocalizations = [NSBundle
preferredLocalizationsFromArray:myLocalizations forPreferences:
[userDefaults objectForKey:@"NSLanguages"]];
NSString* currentLanguage = [preferredLocalizations
objectAtIndex:0];
if (![currentLanguage isEqualTo:@"German"])
{
// Lowercase the displayName so that, for example,
// "Untitled 4" becomes "untitled 4".
displayName = [displayName lowercaseString];
}
}
return displayName;
} -
Am 12.07.2005 um 03:00 Uhr schrieb m:
> It's been pointed out to me that all nouns are capitalized in
> German (and only German apparently), despite efforts at reform
> <http://en.wikipedia.org/wiki/German_spelling_reform>, so I
> modified the code to account for this.
?
The german equivalent of "untitled" is "ohne Titel" (*). Since "ohne"
is not a noun, that's perfectly valid.
Oh, and there have been no efforts to remove the title case for
nouns. The so-called "Rechtschreibreform" did change some other rules
- of which a lot are being re-reformed because they were - well -
just idiotic.
Andreas
(*) GraphicConverter - as a Carbon app - uses "ohne Name" (i.e.
"unnamed"). -
On Jul 11, 2005, at 7:27 PM, Andreas Mayer wrote:
>> It's been pointed out to me that all nouns are capitalized in
>> German (and only German apparently), despite efforts at reform
>> <http://en.wikipedia.org/wiki/German_spelling_reform>, so I
>> modified the code to account for this.
>>
>
> ?
>
> The german equivalent of "untitled" is "ohne Titel" (*). Since
> "ohne" is not a noun, that's perfectly valid.
Just to clarify, Cocoa uses "Ohne Titel" in German. The older version
of my override resulted in "ohne titel" which is wrong. In the new
version, if the app is running in German, it simply punts and passes
the default string "Ohne Titel" through.
> Oh, and there have been no efforts to remove the title case for
> nouns. The so-called "Rechtschreibreform" did change some other
> rules - of which a lot are being re-reformed because they were -
> well - just idiotic.
Hmm... Wikipedia notes that German capitalization rules changes have
been proposed several times since the late 1960s. "Many of the reform
suggestions called for the elimination of German's capitalization of
all nouns, replacing it with a system like that in English, where
only proper nouns are capitalized."
<http://en.wikipedia.org/wiki/
German_spelling_reform_of_1996#History_of_German_spelling_regulation>
_murat -
Am 12.07.2005 um 05:55 Uhr schrieb m:
> Cocoa uses "Ohne Titel" in German. The older version of my override
> resulted in "ohne titel" which is wrong. In the new version, if the
> app is running in German, it simply punts and passes the default
> string "Ohne Titel" through.
Why not just use NSLocalizedString and put there whatever suits you
for the languages the app supports?
> Wikipedia notes that German capitalization rules changes have been
> proposed several times
I'm sure there are all sorts of weird things proposed all the
time ... :) I'm a German living in Germany all my life and I've
never heard of any effort to change capitalization. Note that
Wikipedia also states: "in Britain it was soon suggested that this
capitalization be taken over into English [...]".
Andreas -
On Jul 11, 2005, at 7:27 PM, Andreas Mayer wrote:
>
> Am 12.07.2005 um 03:00 Uhr schrieb m:
>
>
>> It's been pointed out to me that all nouns are capitalized in
>> German (and only German apparently), despite efforts at reform
>> <http://en.wikipedia.org/wiki/German_spelling_reform>, so I
>> modified the code to account for this.
>>
>
> ?
>
> The german equivalent of "untitled" is "ohne Titel" (*). Since
> "ohne" is not a noun, that's perfectly valid.
>
Not "Unbeteitlich"? or "Titellösig"? ;-)
-jcr (I kid, but I really do enjoy German.)
John C. Randolph <jcr...> (408) 914-0013
Roaming Cocoa Engineer,
Available for your projects at great Expense and Inconvenience. -
Am 12.07.2005 um 15:21 Uhr schrieb John C. Randolph:
> Not "Unbeteitlich"? or "Titellösig"? ;-)
>
> -jcr (I kid, but I really do enjoy German.)
Heh. That would be "unbetitelt" or "titellos" respectively. Both are
valid adjectives, but they are not very popular - which you can see
if you google for them (still a few thousand hits for both). :)
But I'm afraid this is totally off topic now ... ;-)
Andreas
