Ai. Bitchy. De maker van het genealogieprogramma dat ik gebruik, Bob Velke, is boos op mij. Omdat ik gesuggereerd heb dat user interface van zijn programma niet altijd even goed is:
I don’t want to stir up a can of worms, and I understand what I ask may not be easily done, what with TMG being programmed in Foxpro, but…
Am I the only one here who would like it if TMG were a little more Windows-standard in its user interface?
A previous poster mentioned the mouse wheel behaviour, my personal pet peeve is the dynamic sizing of things. I can see the (theoretical appeal) of having buttons and labels change size with screen resolution, but in practice this often means I see *less* data on a higher resolution screen than on a lower resolution.
Compare family.gif with familysmall.gif, or, even worse: tree.gif with treesmall.gif…
Redelijke vraag, dacht ik. Ik kreeg al direkt off-list een hele resem mails van “ik vind dat ook” en “ik ben daarom overgestapt naa rprogramma X” en “pas op ze gaan kwaad zijn op u”.
John Cardinal, de maker van Second Site en TMG Utility, allebei zeer veel gebruikte uitbreiding op The Master Genealogist, schreef daarop:
Michel,
The resizing behavior is a direct result of Windows User Interface standards. Bob Velke or someone else should represent the WG position, but my understanding was that the Windows UI rules stipulated that buttons and other user interface elements should be resized when the window resizes. They also felt that if they deviated from that standard they would not be able to put the Windows logo on the box–a big problem.
Personally, I wish it worked differently.
John
Nu, met permissie, da’s klinkklare nonsens. Ik weer:
Are you absolutely positive about this?
As far as I see, the Windows UI rules state “Your application should read, use, and preserve system-wide user interface (UI) settings when displaying customized controls or window content.” I read this as saying buttons and other UI elements should be the size I set them to in the Control Panel.
The rule you’re referring to (I couldn’t find it) is probably one that tries to ensure that when a window is resizable, the UI elements don’t end up huddled together at the top left of a big gray rectangle.
Take the Focus Groups window. What *should* happen in my opinion is that the buttons stay the same size, the text in the buttons also stays the same size, and the right and bottom hand edges of the list of people listbox should be the same distance from the edges of the window. Furthermore, there should be a minimum width and height on that window to ensure the buttons never end up invisible or “scrunched up” like they can now.
Just my 2 cents. I’ve been itching to write a genealogy programme myself sometimes, and if *that’s* not an indication of how frustrated I sometimes get with TMG’s UI quirks, I don’t know what is 🙂
Daaropeen paar uur later deze mail van Bob zelf (de eigenaar-programmeur van het ding):
There’s more to it than that. If resizing worked as you suggest, then the spacial relationship between some objects would have to change as the window is resized, some objects would grow in size and others wouldn’t, and (as you say) we’d have to enforce minimum sizes on all windows. All of those design decisions would have to be made by the _developer_ and that’s a sure way of appeasing half of the people while alienating the other half.
And then there is the fact that people use a wide variety of screen resolutions so what is reasonable resizing behavior (or reasonable limits) to one user will not be so to another.
It is easy to point to specific windows that could easily be designed to resize according to the rules that you suggest. The problem is not resizing the easy ones (like the Focus Group) – it is resizing the hard ones (like the Tag Entry screen)…or explaining to users why some windows resize one way and others resize another.
I think that it is misleading to say that TMG’s interface is not standard is this regard. As far as we’ve been able to determine, Microsoft doesn’t have any rules about what should happen to the objects in a window when the window is resized – except that “the effect of resizing should conform to the needs of the user base” (or something like that). According to our research, there’s no consensus among users about what they expect when they resize a window. But many users have made it clear that they want to have full control over the size of windows, for instance. I’ve even heard some good arguments for making some windows so tiny as to be illegible (but still functional).
I suppose there’s no consensus about what resizing should do because MOST applications don’t allow the user to resize windows (especially those with data entry fields, buttons, etc.) and those that do put very strict limits on it. So, like many other areas in TMG, the program is criticized as being “quirky” because, while allowing the user to do things that they can’t do in other programs, it exposes those users to issues that they have never encountered elsewhere. I’m not sure that’s a bad thing. After all, many people want those features …and others don’t have to use them.
There’s a easy way for TMG to avoid being labelled as “non-standard” – that is to impose all of the same limits that other programs do. Or maybe we should just be proud of being non-standard.
Ulp. De man zelf. Nu, niet dat ik geĂŻntimideerd ben, zeker niet als hij redelijk duidelijk fout is. Vandaar:
I actually don’t agree with you on this one, but I guess we’ll have to agree to disagree since there’s not much I can do about it on my end (bar actually making my own TMG :).
You’re right that I took the “easiest” window to make a point, but I’m not sure what percentage of people in the user base have *ever* changed the site of the tag entry screen: make it smaller and the text becomes practically too small to read, make it higher for instance and (paradoxically) text in the entry fields becomes larger while the input boxes themselves only scale in height, so you end up seeing less on a bigger input window!
As for explaining things to users: the fact is that most users spend most of their time other programmes than TMG, probably Microsoft Office-type things. And most other programmes do not have the UI “quirks” you describe. Ergo TMG is non-standard.
Now I have no intention to be unconstructive here, so if you’re interested I could create some working Windows mockups of how I think things might be redesigned…
Da’s toch niet onconstructief? Het is zelfs waar dat ik een resem inputschermen van TMG ooit hermaakt heb, in .NET no less, gewoon om te zien of het wel haalbaar is om ze standaard-windows-achtiger te maken (het is haalbaar).
Niet met Bob gerekend, die is nu blijkbaar echt boos geworden:
Can you point me to a Microsoft Office program that allows resizing of a window that has a button on it?
If you like, we make make a check box that disallows all such resizing, thereby making TMG “standard” in your eyes.
Bob Velke
Wholly Genes Software
Brrr… Dat is dus zo’n mail waarmee een flame war begonnen wordt. En ik weet ook niet of mijn antwoord er veel goed aan gaat doen:
I get the feeling you’re taking this very personally. Please understand I meant no disrespect or anything, I was only trying to be constructive.
As for your question: the nearest thing to genealogy in Microsoft Office is Outlook. And the nearest thing to a person data entry screen there is the contact function.
Loads of buttons, loads of different entry boxes and lists and whatnot.
And it *does* resize. In a standard way.
Paraphrasing usability guru Jakob Nielsen: if “everyone” does it differently to the way you do it, then “everyone” is right, and you are wrong. Even if you aren’t wrong in your own view.
Because in usability and user interfaces, the majority is (almost) always right.
Het is gewoon een feit dat ik denk dat ik gelijk heb, en Bob heeft zichzelf schaakmat gezet door te vragen naar een voorbeeld uit Office. Want het contact-schermpje in Outlook is wel degelijk bijna exact hoe het data entry-scherm er in TMG zou moeten uitzien. Het doet begod bijna hetzelfde zelfs!
Ik ben eens benieuwd wat hij nu gaat zeggen.