To read all comments associated with this story, please click here.
Sure, if you go along with the one user fits all approach, then yes, the developers should sit down 'the user' and test him till he bleeds to find out which method is best.
Being rather subtler than that, however, they have tested, and provided, an optimal default that 99% of users are expected to be satisfied with. People with non-standard hardware or software requirements however, can, with a little research, find out how to make chrome suit their particular needs more often.
This sort of customisability is applauded in most Open Source software, why not this piece?
I voted you up because I think you bring up a good point, but I disagree. It could cut either way. I agree with you that more defects in the code will be manifest by giving users more flexibility with how they use the program, but the argument could also be made that forcing the developers to accommodate a larger variety of usage scenarios would force the overall code quality to be higher to reach release quality.
From reading their development website, one of the reasons they went with the option of operating in the single-process model was because it's easier to debug using the standard Visual Studio debugging environment. Once they had the feature, what's the point of suffering the pain of removing it, especially since they expect some of the users to also work on developing Chrome's open source codebase?
[Posted from Chrome, on which I just seem to have hit a scrolling bug]





Member since:
2006-01-11
... but when this is production code, giving the general public this knob that can be set four ways is just shifting work from the developers to the users.
There are also going to be more bugs; the four different modes of operation are going to tweak different bugs. And if a design goal is that one tab can die without hurting the others, and you put out a comic book bragging about this, why not just implement it that way and be done with it?