I would like to put in my two cents for making Dragon NaturallySpeaking 10 work at about "50%." DNS 10 is a terrible program in a lot of ways. It's interface is over-engineered, clumsy, unintuitive, and packed with features that the average user never even looks at. People who don't know DNS say, "I'd love to dictate into word, format by voice command, etc." People who know DNS well, say "just give me accuracy and speed, and forget everything else." Those people usually tend to be the natural DNS constituency: either disabled or want to churn out a tremendous amount of text without typing.
I think my point here is that happiness depends not only on % but on the type of program. Not all programs are created equal. Not all features are a good idea.
Susan Cragin
2009/4/18 Susan Cragin susancragin@earthlink.net:
I would like to put in my two cents for making Dragon NaturallySpeaking 10 work at about "50%." DNS 10 is a terrible program in a lot of ways. It's interface is over-engineered, clumsy, unintuitive, and packed with features that the average user never even looks at. People who don't know DNS say, "I'd love to dictate into word, format by voice command, etc." People who know DNS well, say "just give me accuracy and speed, and forget everything else." Those people usually tend to be the natural DNS constituency: either disabled or want to churn out a tremendous amount of text without typing.
I think my point here is that happiness depends not only on % but on the type of program. Not all programs are created equal. Not all features are a good idea.
That also brings up a good point as to why focusing on applications - even those used by a large number of people - is only part of the equation: every user is different.
If you take a sample of Office, PhotoShop or iTunes users and see what features they use, there are bound to be differences. You use iTunes just as a media player? Want to download songs from the iTunes store? Want to sync with your iPod? All of these hit different areas.
Can't hear? Fixing sound issues isn't going to help this user.
Can't see? This user isn't going to be fussed about graphical issues. They will be more interested in accessibility support (MSAA, UI/Automation) and would use something like DNS to interact with the applications. Or perhaps get an MSAA/UIAutomation to Gnome/KDE accessibility APIs so they can use the system's screen reader.
So here, the user-by-user approach is more useful.
- Reece
On Sat, 18 Apr 2009 15:22:34 +0100 Reece Dunn msclrhd@googlemail.com wrote:
That also brings up a good point as to why focusing on applications - even those used by a large number of people - is only part of the equation: every user is different.
Happiness is a subjective state that depends as much on the user's expectations as it does on actual performance. I'd count myself as a mostly happy user, but I came in with fairly low expectations and was pleasantly surprised. Users with unreasonable expectations are always going to be frustrated.
2009/4/18 Rosanne DiMesio dimesio@earthlink.net:
On Sat, 18 Apr 2009 15:22:34 +0100 Reece Dunn msclrhd@googlemail.com wrote:
That also brings up a good point as to why focusing on applications - even those used by a large number of people - is only part of the equation: every user is different.
Happiness is a subjective state that depends as much on the user's expectations as it does on actual performance. I'd count myself as a mostly happy user, but I came in with fairly low expectations and was pleasantly surprised. Users with unreasonable expectations are always going to be frustrated.
That is true. Wine continues to improve, so more applications tend to work. For those applications, there are bound to be some things that don't work right or look right. And then there are regressions, but such is the nature of software :).
Out of interest, which applications do you use? And what are the issues that, when resolved, would make you a happy user? (You could be our second user in this experiment ^_^).
Thanks, - Reece
2009/4/19 Rosanne DiMesio dimesio@earthlink.net:
On Sat, 18 Apr 2009 15:22:34 +0100 Reece Dunn msclrhd@googlemail.com wrote:
That also brings up a good point as to why focusing on applications - even those used by a large number of people - is only part of the equation: every user is different.
Happiness is a subjective state that depends as much on the user's expectations as it does on actual performance. I'd count myself as a mostly happy user, but I came in with fairly low expectations and was pleasantly surprised. Users with unreasonable expectations are always going to be frustrated.
I'm so happy with Wine that I volunteered (several times) to help keep the Debian packages up-to-date. I've also submitted a couple of patches, had quite a few bugs fixed, and been given admin capabilities on AppDB (which is quite a compliment). I'm probably as happy as a Wine user can get. The apps and games I use in Wine almost all work 100% the way I want.
Right now, there's one thing bugging me: bug 14939. If Dan (or others) would like to implement a method of deferring S3TC texture decompression to the appropriately licensed GPU, assuming there are no legal issues with this, I'd be ecstatic. But I'm sure the D3D devs have better things to do. :)
Note that some users get annoyed when a patch that fixes their problem is rejected because it's a hacky hackish hack and would adversely affect a lot of other apps. If we focus on one of these users, and try to make them happy, should we break a bunch of stuff just for them? I think Wine is making excellent progress in supporting win32 apps with the current development model. And of course, if it ain't broke ...
2009/4/18 Ben Klein shacklein@gmail.com:
Right now, there's one thing bugging me: bug 14939. If Dan (or others) would like to implement a method of deferring S3TC texture decompression to the appropriately licensed GPU, assuming there are no legal issues with this, I'd be ecstatic. But I'm sure the D3D devs have better things to do. :)
The sad thing is that S3TC decompression is just plain trivial.
On Sat, Apr 18, 2009 at 11:36 PM, Henri Verbeet hverbeet@gmail.com wrote:
2009/4/18 Ben Klein shacklein@gmail.com:
Right now, there's one thing bugging me: bug 14939. If Dan (or others) would like to implement a method of deferring S3TC texture decompression to the appropriately licensed GPU, assuming there are no legal issues with this, I'd be ecstatic. But I'm sure the D3D devs have better things to do. :)
The sad thing is that S3TC decompression is just plain trivial.
Maybe that could be solved in the same way as the patented Freetype code: disable it by default, but let commercial Wine packagers (and individual users obviously) have the choice of compiling it in. Something like ./configure --paid-for-patents.
Remco
On Sun, Apr 19, 2009 at 12:31 AM, Remco remco47@gmail.com wrote:
On Sat, Apr 18, 2009 at 11:36 PM, Henri Verbeet hverbeet@gmail.com wrote:
2009/4/18 Ben Klein shacklein@gmail.com:
Right now, there's one thing bugging me: bug 14939. If Dan (or others) would like to implement a method of deferring S3TC texture decompression to the appropriately licensed GPU, assuming there are no legal issues with this, I'd be ecstatic. But I'm sure the D3D devs have better things to do. :)
The sad thing is that S3TC decompression is just plain trivial.
Maybe that could be solved in the same way as the patented Freetype code: disable it by default, but let commercial Wine packagers (and individual users obviously) have the choice of compiling it in. Something like ./configure --paid-for-patents.
Remco
Most drivers offer it these days and I believe also Mesa by default but you need to enable it using driconf or so.
Roderick
2009/4/19 Roderick Colenbrander thunderbird2k@gmail.com:
On Sun, Apr 19, 2009 at 12:31 AM, Remco remco47@gmail.com wrote:
On Sat, Apr 18, 2009 at 11:36 PM, Henri Verbeet hverbeet@gmail.com wrote:
2009/4/18 Ben Klein shacklein@gmail.com:
Right now, there's one thing bugging me: bug 14939. If Dan (or others) would like to implement a method of deferring S3TC texture decompression to the appropriately licensed GPU, assuming there are no legal issues with this, I'd be ecstatic. But I'm sure the D3D devs have better things to do. :)
The sad thing is that S3TC decompression is just plain trivial.
Maybe that could be solved in the same way as the patented Freetype code: disable it by default, but let commercial Wine packagers (and individual users obviously) have the choice of compiling it in. Something like ./configure --paid-for-patents.
Most drivers offer it these days and I believe also Mesa by default but you need to enable it using driconf or so.
If you read the bug report, you'll see the app is not trying to load an S3TC, but it's asking DirectX and/or video driver to convert an DXTC texture to ARGB. If it was just loading an S3TC/DXTC texture, I wouldn't have a problem because my card and drivers support it (closed nVidia drivers). This is something that needs to be implemented in Wine somehow, even if it defers decoding to the GPU to do it.
You can identify this first user group by searching on secular requests - Novel showed us the first line is around Adobe clients. Dreamweaver ( which work OK now ), Photoshop, Flash, InDesign maybe - so webdesigners + DTP peoples can be 'the first' client.
They are many millions now - no doubt they are more important than gamers.
All those users need a fluid experience ( install ) - and I ask myself - is so impossible a kind of deal with Adobe to help that ?. John Nack respond me they already do that ( they work with Wine ) but I'm curious if they really do a single step on this direction ...
-
Ben Klein -
Henri Verbeet -
Reece Dunn -
Remco -
Roderick Colenbrander -
Rosanne DiMesio -
SorinN -
Susan Cragin