On Jul 4, 2011, at 11:32, Ulf Dunkel wrote: Hi Christiaan. No, I'm saying that the one-for-all approach can lead to unacceptably ugly UI. And this should be fixed in code. And fixing in code can be more difficult and less stable for more complex UI.
This is interesting. Can you give me one ore more examples of "unaccaptably ugly UI" layouts, please?
If the difference in string length for a button with a large title is large between localizations, then you may end up with a relatively small title in a huge button (for instance in Chinese). That's really ugly, and I honestly think unacceptable.
The one-for-all method does NOT cover everything. Unless you accept just ugly UI. I think that can be unacceptable in certain situations, and saying otherwise IMHO makes you a bad developer. You should not accept bad UI. Again, it depends on your UI how far you need to go.
Well, I don't really like the strategy that arguing on "ugly" UI layouts defines who is a bad or a good developer. Who will define what's ugly and what is not?
Again you misinterpret my words. I am saying that UI *can* be ugly. And it can occur due to the one-for-all approach. Leaving too much space also can be ugly and unbalanced. If you don't recognize that fact of life, I think you're a bad developer ("you" in general, not personal). In fact, there are better balanced UI layouts than others, and Apple's recommendations are fine in a way, while they don't really dig into the issue of localization. They just scrap it - and even Apple has shown really ugly UI layouts in localized versions of Mac OS X apps.
In my terms, "ugly" mainly refers to usability, cropped text objects and clipped elements. There are many apps outside which look nice in English but rather unusuable or damaged in localized versions. This is what I am talking about all the time.
Those are perhaps the worst, but not all, also too much space can be really ugly. The optimum is to have exactly the space you need, nothing more, and certainly nothing less. I can get this, you can't. I like to have the best layout if that is possible. Your approach is necessarily always a compromise, and trust me, sometimes an unacceptable one (you may not run into that, but then you're just lucky). I don't need to compromise.
I appreciate your approach and it will surely give fine results. (Honestly, I have no knowledge of your designed apps. If you could mention some, I would really like to browse their UI and see if I like them, too.)
I use this approach in Skim. The only compromise I make in our "One For All" layout is, that the longest localized text defines the size of the object. And I personally find it annoying to have a tiny OK button with e.g. 50 pixels width on a large screen while a unified pair of OK/Cancel buttons with 110 pixels works fine in all languages we have localized until today - AND give a greater opportunity to hit them with the mouse pointer.
---Ulf Dunkel
And I also take care of the tiny OK button, really. And in a consistent manner. That's the beauty of it.
But I am not talking about such situations, I am talking e.g. about situations with buttons that have a large title. For instance in Sparkle. That can lead to VERY ugly situations in your approach.
Again, my main point is that the one-for-all approach can work nicely for SOME apps. But for some situations it MAY NOT work. And this is true for basically ANY approach, unfortunately, because Apple has provided NO good solution, and forces us to make compromises somewhere. I like to make the compromises in the development, not in the result.
Christiaan
|