brkirch said:
I agree, I have heard a lot of not so great things about Parallels support. As for communication, I think there needs to be a list of known issues for each build that is actively updated as new issues are discovered. There needs to then be a working resolution for each issue available, whether it is downgrading, reinstalling Parallels, or even reinstalling Windows, whatever is necessary to fix the problem until a more permanent fix is available.
bk...
I think that a "bug list" for a product such as this would have to be dynamic as things would change quickly.
As far as their being a resolution to every issue, I don't believe that is possible. IE I think there will with any complex product be certain things that simply don't work until fixed in a future release.
The best way to deal with these things is to simply acknowledge them. Example:
iPhone will not sync with Parallels 3.0 build XXXX.
Solution: None. We expect to add iPhone support soon.
This is clear communication that there is an issue using iPhone with Parallels. There is NO work around, no solution. But they know about the problem.
This gives the user the chance to say, ok... I can live with this, or I cannot. Either way the forum (and Parallels) is not blasted with messages about iPhone and users are given clear information.
As you say, when a work around is available obviously it should be shown and documented with the item.
Some companies fear that if they published a bug list the list would be so long as to dissuade possible purchasers of the product. I have found the opposite to be true. Very few people expect perfection. If they can scan the list and see that the item they are interested in using is NOT on the list of problems then they feel better about their purchase.
M