Comments
Comment by Dave2:
¶
Yeah… try working with the tragedy that is Windows Vista for more than an hour and see how your attitude about Mac OS X changes! It may not be perfect, but things could be worse. Things could be a LOT worse.
There are parts of the Mac OS that I dislike, but overall I am thrilled that there is a viable alternative to being stuck with a Windows POS all day. Oddly enough, some of your opinions as to what is bad are things I like, so it’s all subjective anyway. :-)
Comment by Carl:
¶
I always find it odd when you bash Apple’s UIs. Not that those criticisms aren’t true, but are you ever going to fix the UI for UnicodeChecker? I mean, it’s an incredibly useful app with a basically terrible interface. Seriously, a “utilities window”? Why not be honest and call it the “let’s-jam-everything-besides-character-lookup-in-one-spot” window. And exactly how many localizations do you have? These days, open source apps like Adium and Smultron have localizations for a dozen languages. AFAIK UnicodeChecker doesn’t even have a German localization! And you know native German speakers. For example, you!
Which isn’t to say that you’re not allowed to criticize Apple before you fix your own app, just that you really ought to include more disclaimers along the lines of, “Of course, I myself know how hard it can be to find the resources to do X, Y, and Z…”
Comment by ssp:
¶
Carl, including such disclaimers all over would make me even more verbose. Of course writing operating systems or building computers isn’t trivial. But that doesn’t make things better.
On Apple’s level, there seem to be two problems. One of them, like the background pictures or the new folder icons would be labelled bad taste (although I think the latter are also a usability problem in an obvious way). So there’s a huge company which has shown that they in principle have people employed who are very skilled at graphics and UI work. But you get a results which show none of that.
While it’s charming that you compare earthlingsoft to Apple, please let me point out a few small differences: earthlingsoft consists of two enthusiasts working on software in their free time for what essentially is nothing. Apple, however are a huge corporation of thousands. They also seem to be quite profitable. There are orders of magnitude between the numbers of users earthlingsoft have and those Apple has.
Another big difference is that we don’t claim that UnicodeChecker is fully localised to German when it isn’t. And usually we also try to be truthful with our other claims. Apple, however, don’t list notes of incomplete localisation in their ‘new features’, just as they don’t list other shortcomings of updates.
So, if you studied the feature list of OS X.4, you wouldn’t have known that it stopped supporting file sharing over AppleTalk. You would have forked over the cash and that joke would have been at your cost. Compare that to UnicodeChecker. If you downloaded it in the impression that is was localised, you could just curse earthlingsoft and delete your download.
There are of course reasons for UnicodeChecker not being localised. They mostly boil down to it being a lot of work, particularly to get the Help in a readable shape. All that while it seems safe to assume that UnicodeChecker’s users whose mother tongue is German are capable of understanding English as well. Particularly as I doubt that you could belong to UnicodeChecker’s target audience (Unicode, web design, programming) without understanding English.
As far as localisations of applications are concerned, I’m split. Many open source applications are localised but quite a few of them quite badly so. The open source thing means that people feel compelled to throw in their own localisation. And the people responsible for the release may not be able to judge the localisation’s quality, so this is very tricky.
Finally I think that you underestimate UnicodeChecker’s ‘Utilities’ window. These are all tools which process a string by converting or analysing it. They are even implemented as a plugin architecture to which you can add your own plugins. If you have a better idea, please let me know.
Comment by Carl:
¶
I’m not underestimating the utility window. It’s very powerful. That’s the problem. It’s become more powerful than the main window, but the UI doesn’t reflect this. On top of that, (on my system at least) it opens up with the window too narrow to show all the icons in the toolbar, so it has a chevron instead with the last two icons hidden behind it.
How I would redo the UI would be to re-prioritize its functions by disassembling things. Right now, the main windows does three things: it lets you pick out characters, it shows you what text you’ve entered, and it shows you the properties and fonts of whatever the last characters in the box are. These things should be split up.
On the character selection side of things, the long scrolling window on the side of the main window is basically useless except as a way to waste time looking at what other characters just so happen to be near the character you’re actually interested in, so it should be broken out into its own floating inspector instead with a Cmd-# toggle. The search function in the main window is too useful to be buried under a magnifying glass, so it should also be broken out, but while you’re doing that, you may as well combine it with the long character list. The number input box is actually useful, but it’s also basically a variation on searching for a character to insert into the main window. So, those three things should go together. The character list window should do live searching and be resizable, so that if you want to see the names of the characters in the list, you can (as is done with the find box today). If you want to get really fancy, you could have sortable column headers at the top, so people could look at thing ordered by name instead of by code point.
Similarly, on the properties side, the random bits of info character underneath the main window can be put in a floating inspector, just as is done every other application. One other thing you can do is have the properties floater reflect whatever character the cursor is next to, instead of whatever character is last in the list. Maybe trigger it with Cmd-I instead of a number. You could do Cmd-T for a font box, or you could put the font info as a list in one tab of the properties inspector. That would be a bit more convenient, since you wouldn’t have to click to pop up a list of the useable fonts each time you inspect a new character.
All of the utility window functions have a box labelled input. That should be dropped, and they should all just reflect what’s in the main window, which we may as well rename the “input window”. While this is done, you might want to also move the icons for the different kinds of text transformations from the top of the window to a source list on the side, since there’s already more than be easily fit onto the top of the window. Doing that would let you break out the various sub-functions that are now hidden in there, by giving eg. “HTML → Unicode” and Unicode → HTML” their own source list entries, as well as the sub-parts of IDNA and the various Normalization modes.
Of course, I only want these radical changes to the UnicodeChecker, because it’s such an awesome, useful app. I’m just not convinced that its UI lives up to the expectations you put on others.
Comment by ssp:
¶
Thanks for the feedback Carl.
I think I disagree on many of your points, particularly the use of floating windows which I just consider to be messy and of which I wouldn’t want more than one if they cannot be avoided at all.
Obviously everyone’s use of the application differs and personally I find the main window still the most important one. Browsing and exploring Unicode is our main idea for UnicodeChecker. And the main window offers exactly that.
Most of the Utility window’s conversion features are also provided as Services and to AppleScript (as well as in our Framework which could be used from your own application). So if you need some of them repeatedly, you’d probably be better off not dealing with UnicodeChecker’s UI at all. At least that’s our idea of the application: you can explore and look things up and you have a number of tools up your sleeve which you can invoke from outside UnicodeChecker, i.e. right where you need them. That’s our idea of not getting in the way.
As for the Utility window’s toolbar, just turn it off. It shouldn’t be there. In my opinion, anyway.
We discussed a more prominent Find feature, but issues there remained both with the UI (having another text field around would be more confusing plus the difficulty of implementing a graceful inline display of and the underlying software (with the Unihan file installed, activating search can take a moment and consume quite a bit of RAM, so you don’t want to accidentally do that). We currently don’t have improving this as a high priority.
Particularly as UnicodeChecker offers support for Spotlight which lets you query things from anywhere in the system, thus necessitating even less interaction with UnicodeChecker itself. With the improved speed of Spotlight and the (upcoming) Quick Look support in X.5, this method should become a viable alternative to in-UnicodeChecker finding.
Comment by Mike:
¶
Finally someone talking about Mac OS X localization. We here in europe pay 50% more, at least, than americans, for any Apple product and what we have? a “fully localized” OS in english. What about Mac ability to speak in other languages? what about voice recognition? dictionaries in Portuguese, spanish, german, etc.? American companies generally do not care with other languages but english, most american companies not even realize that there are other countries outside the USA. I love Apple, but they produce american products for american people even after Steve Jobs saying that 40% of Apple’s revenue come from outside the USA…
