Your definition of bugs or enhancements depends greatly on your level of agility.
http://agilemanifesto.org/
Itâs always a feature for software vendor because they can always charge for it.
Itâs a bug for the customer because they donât have to pay for it. The vendor shouldâve known/asked better.
Try to set a different font in Vista, reboot (you never know if it will help or not) and then look at how many fonts are unchanged, ie are the âdefaultâ Vista font. This bugs me, a lot.
The idea of using the default system font is also not really workable. The default system font on XP is different than it is on Win 2000 and also Vista. And I might be creating apps on Vista that I will also want to run on XP.
So the better solution is to just let me choose or to define a font named system that I can select for my forms so that the actual font used is chosen at runtime. But it is hard to make a designer do this.
Personally, I prefer the option of giving users the option to choose through configuration. As far as I know there is no way to choose which font the forms designer uses by default. And to me this is wrong. Itâs not a bug. But itâs not right either.
You know, call me silly, but I canât decide which of the two font examples you posted in the form image are supposed to look like a male donkey. I find both of them to be perfectly readable on my low-resolution laptop monitor, and if I understand your example correctly I think the Microsoft Sans Serif font (thatâs the one on top, right?) looks better and is easier for me to read. Thatâs largely do to me being partial to wide fonts though, I never liked reading narrow print, but the difference is subtle anyway.
So I guess youâre absolutely right, its a complete matter of taste. You are correct that the application should default to the system font, but really thatâs only important if the user changes their system font to something they can read better. Iâm pretty certain that 75% of Vista users donât even know that they can change their system font in the first place⌠Even if they do (I do) the system font is chosen to be readable, so thereâs not really a need to change it unless you just canât stand it for some reason.
Iâm ranting a bit here on how I disagree, but then again I donât particularly agree with a lot of Microsoftâs design guidelines, which brings up that matter of taste again.
When comes to bugs/defects and feature requests there can be a way to detect. This is obviously expecting a bit from the project or company. But if the project has good requirements/expectations of what the finished product is going to be it makes the process easier. Then in your QA or review of items submitted you use those requirements. If it is going away from the direction of the requirements it is a feature request. If it directly relates to a item associated with your product direction then it is a bug or defect.
Bottom line you have to research the entry, and you need documents to research against. Otherwise your right you canât make a clear distinction. Then if what is reported is a showstopper you obviously need to take care of it immediately. But do it towards the direction of your requirements and or product vision! 
The biggest problem when dealing with a definition of a bug versus an enhancement (or a design omission) is perception. If you coded a program to do one thing, and all of the users start using it for something it wasnât quite intended to do, is it your responsibility to âfixâ it to do that thing? No. Itâs not a bug, but if 98% of your user base is using your screwdriver as a hammer, chances are, youâre going to make one section flatter and heavier and add a handle and call it screwdriver 2.0.
I hacked my VB6 to use Segoe UI by default. Anything that doesnât explicitly have a font set is now no longer MS Sans Serif.
I donât like Vista that much, but the fonts are niceâŚ
Party like itâs 1996, folks, because youâll get MS Sans Serif, and youâll like it.
If you actually used MS Sans Serif, the bitmap font, at any size above 12 point, it would look like crap. Fortunately, your Properties Pane shows that youâre using Microsoft Sans Serif, the OpenType font, which really doesnât look bad at all. All things being equal, bitmap fonts are usually going to look worse than OpenType fonts.
That being said, was there ever a time when VS.NET didnât do this?
I suspect the problem is twofold.
Firstly, Microsoft tried to do the seemingly logical thing but developers abused it. In an ideal world, GetStockObject(SYSTEM_FONT) would return you whatever font was the default for the system. However everybody and thier dog wrote their app assuming that the entire world had the same system font they did, and when it wasnât their app didnât draw correctly. Microsoft then tried to address this by creating DEFAULT_GUI_FONT, which was promptly abused in the same way. These sort of abstract definitions always end up getting stuck forever because of app compatibility.
Secondly, this is the 21st century now and we all have hundreds of fonts installed. There is no such thing as the system font. Windows is perfectly happy to set different fonts for captions, menus, dialogs, status bars, command prompts, etc, etc. Which of these is the system font?
IMHO the guideline about hardcoding Segoe UI is just as busted as using SYSTEM_FONT. The next time Microsoft gives itâs UI designers some slack theyâll go changing all the defaults again and weâll have to have another round of why are these lame apps using (System|Microsoft Sans Serif|Tahoma|Segoe UI) instead of (New Hotness)?
Wow, way to sell all of us up the river, Jeff. These poor pitiful users, why should they ever have to suffer the pains and arrows of an application that doesnât work exactly the way theyâd like, but never bothered telling their developers?
The difference between bugs and new features is clear: if it was in the spec or could be reasonably implied by the spec, but isnât in the application, itâs a bug. Say, for example, you write a search page for your site that delivers hits in order of relevance. After a few days of using it, the users decide that it would be better to sort the results by date. Is this a bug? Under the logic of you want to do something with an application (or website) ⌠[is no] different than not being able to do something due to an error message means, that, yes, this is a bug. Donât mind the fact that nearly all search engines nearly sort by relevance, or that the user never thought of (let alone requested) a date sort in the first place. Itâs a freakin bug, so fix it free, let your business owners yell at you and complain to their managers about how inadequate the IT department is. Take your lumps like a man, dammit.
BTW, the Visual Studio font issue is clearly a bug because it doesnât follow itâs own documented standards. If those standards didnât exist, it would be a feature request. Anything that starts with It would be nice if and canât be tied back to some type of document is a feature request, period.
Division between bug and feature request is just a crude way of triaging user demands. Such triaging is absolutely necessary, unless you want to have zero control over how you work. I think that weâd remove this distinction and then quietly introduce another one, like Important requests and Less important requests. Whatâs the point?
Microsoft has the strangest approach to bugs Iâve seen. User reports that never result in a bug being on the official bug list? Common. Bugs being on the official list for multiple releases without fixes? Not as rare as it should be. Both phenomena occurring at the same company? Microsoft.
Two things:
(1) Thereâs no difference between a bug and a feature request from the userâs perspective? Thatâs just condescending. When it comes to cars, Iâm about as naive a user as could be, but even I know thatâŚ
- If I wish that my car seats were warm as soon as I got in the car in winter, Iâm wishing that my car had the heated seats FEATURE.
- If my car doesnât slow down at the bottom of the hill when I press the brake pedal, thereâs a BUG in the braking system.
I credit my customers with a similar level of discernment.
(2) You chose a poor example. Your overall point (Microsoft slow to change!) may be valid, but I canât blame Microsoft for leaving the default font to be one that actually EXISTS on 78% of Windows machines.
The way these posts are written, they sound like Jeffâs stream of consciousness rather than an organized article with a point. See that over half the article is irrelevant to the topic, which presumably is how to distinguish a bug from a feature request. The only relevant text is the first 3 paragraphs and the last paragraph. The article ironically suddenly concludes that the whole article has been a waste of time and that we should spend more time on actually doing things.
As many have stated, bugs are when something doesnât work according to spec, which doesnât necessarily mean a crash. Feature requests are for the system to do something new or different, with no implication that the system was wrong, i.e. not working according to spec.
Jeff defended himself in an earlier post that when he writes he usually argues strongly for a weakly held (by him) opinion. In effect, heâs just writing his knee-jerk reaction to whatever happens to come to mind and let the commenters do the thinking and writing of thoughtful ideas for him.
@Bob G.:
What about: When temperatures are below -X degrees celsius, the engine wonât start?
This is a common problem in Alaska and the Canadian Territories (north of the Provinces). You need to hook up a heater to make the engine warmer before you can start it. I canât remember why â maybe the gas freezes or just gets too viscuous, maybe the exothermic reaction becomes unsustainable, maybe the metals get too tight together and cause friction, whatever.
Is that a bug (engine wonât start in commonly-encountered conditions) or a feature request (engine that can operate at very low temperatures, perhaps by heating itself)?
to sum up:
if the coder has to eat the cost, itâs a bug.
if the user has to eat the cost, itâs a feature.
Regarding the article: the Visual Studio forms designer shows the lowest common denominator font that is guaranteed to be present on all systems that can be targeted by a Windows Forms application.
The real issue is the fact that WinForms does not have a mechanism for automatic runtime discovery of the appropriate system font. Thatâs why you need to explicitly specify a font in the first place, and thatâs why the VS designer cannot substitute Tahoma or whatever â you donât know if this font will be present on the target system.
This was fixed in the Windows Presentation Foundation, by the way. Since WinForms is obsolete (and the article Jeff linked to is from 2005) I donât expect Microsoft to do anything about this issue now.
All of you who claim itâs a BIG difference between bugs and feature requests are thinking like developers. I beleave there probably should be at leas one more category between bug and feature request:
unintuitive behaveour or similar. Most users donât know the spec and even if they do, a developer will understand the spec differently than a user. If the software behaves as we geeky developers expect, but the user donât, like 2 is sorted after 10 (because obviously you should have written 02) itâs not a bug (the spec sais sort, it does sort by ascii order), neither is it a feature request (you claim itâs sorting but it doesnât do it correctly), itâs unintutive. (You can probably find better examples)
The big problem is that if you just ignore this category you end up creating a pool of users who has learned the quirks of the system, and later if you actually fix the problem the new users will be happy and the older users will be confused.