QR in current SVN

Discuss features as they are added to the new version. Give us your feedback. Don't post bug reports, feature requests, support questions or suggestions here.
Forum rules
Discuss features as they are added to the new version. Give us your feedback. Don't post bug reports, feature requests, support questions or suggestions here. Feature requests are closed.
bolverk
I've been banned
Posts: 280
Joined: Mon Feb 02, 2009 5:39 pm

Re: QR in current SVN

Post by bolverk » Sat Aug 01, 2009 12:41 pm

Roberdin wrote:I don't believe that is helpful at all. If a setting is greyed-out or simply not there, it does not explain to me why that is the case; no more than if it has no effect.
Using a visual indicator to communicate the status of a dependent/conditional control is a fundamental tenant of UI design, and has been for well over a decade. If you don't believe me just take a closer look at the UI of almost any software you have access to, your OS whether it is Windows, *nix or Mac, any modern internet browser, office suite, literally thousands of software applications desktop server and web based, utilize this basic design principle. If you like I could post screen caps. :) The fact of the matter is that phpBB treats dependent/conditional controls three different ways in the application today. They use two methods of visual indication, "graying out" and non-display if the dependency/conditional is not met and lastly they use no visual indicator regardless of the dependency/conditional being met. This last scenario is what Acyd Burn brought up as his justification for enabling QR by default, because some users would definitely become confused as they would be allowed to set the forum QR switch to enabled and yet still have the possibility of it not displaying in the forum because of the global conditional not being enabled. My response was, and still is, do not allow such a situation. Remove the ability to set the forum switch unless the global switch is on. Utilize standard UI design principles defined not by me btw :P , but by the software industry as a whole. Be consistent in your own UI design throughout the interface, don't treat the same control types differently across features. :)
Roberdin wrote:Similarly, I don't believe that there is a ubiquitous "natural language" shared by all non-developers in looking at this.
You can believe or not believe as you like, it does not negate the fact that there are entire curriculums built around it's existence and applicability in software design. As a lead software engineer and later project manager I was required to take classes in how to bridge the gap between natural language in software design & requirements definition and coding logic.
Roberdin wrote:...but they also have the simultaneous burden of being concise and remaining equivalent across all cultures who speak the language.
I disagree there. They only have the burden of being generally understood to the target audience, in this case native English speakers as the only language pack that ships with the package is English. The ambiguity of natural language that you describe in your example is precisely why the languages feature exists and what language packs are designed to address. One language pack can not be expected to meet multiple definitions of the same words across cultures. :)

Post Reply