On 2012.04.18 08:37, Ludovic Rousseau wrote: > I want something that adapt to the browser (not the screen) the USER > wants to use.
No. You want something that looks better on small sized browser windows (which I agree needs to be improved), but, if we go with your proposal, that will also make it less readable on large sized browser windows. Hundreds of thousands of web sites that *limit* the width their text can expand to on large screens, to a fixed size, very much prove that the vast majority of content creators see spreading to the full width of the browser, on large width, is not a desirable behaviour, and this is a view I very much share with them. So you point seems to be: All these people are wrong - going full width on wide browser windows doesn't make the content less readable in any significant way. I don't think that view is sustainable. > As a user I don't care if you find it ugly to use a very large > browser. Yes, as a single user, what you find pleasing or uncomfortable is your view, and your view alone. Which is why, rather than argue "well, *I* see it differently so we should just do it *my* way", I instead tried base my course of action on considering what is likely to benefit our users at large, and this is why I stated that, considering that more users are expected to come visit libusbx.org with a wide browser than a small one, if the choice has to be *only* between providing a more appealing experience to users with a wide browser window, or doing the same for users with a small one, in terms of expected numbers, we should try to satisfy the wide ones first. Now of course, the better approach, which is the one I propose and which should satisfy us both (unless you want to dispute that text content should adapt to the browser width always and that all the people who create content using columns are wrong), is to wrap to the browser window below a certain size, and wrap to a specific column size rather than the window size above. But we do not yet have a proposed solution for that, in the absence of which we have to choose between two not-so-good solutions, one of which, without trying to dispute the *logical* reasons that made me indicate why I think it is still the better approach for our users, you say can only be wrong because it inconveniences *YOU*. Please consider that, when given a choice, most users may not want a text that goes full width on a large browser, but rather than resize their browser window to obtain that, they will expect the content creator to set an upper limit for them. And there's also the matter of what the content creator intended vs what people get, where, usually, the intent of the content creator, which in this case is readable text and paragraphs that look like what you would see in a regular book, prevails. > It is MY choice as a browser user. Please, do not restrict MY > choice with arbitrary decision. Unless you have the choice to define columns size on all the sites you browse, which I'm not aware any browser can do, it is not your choice to force a column size to expand above a specific size if the creators of the site, who are the ones responsible of the content, think (which I argue makes a lot of sense) that having text occupy full width on large browser windows is not for the best and will diminish the user experience. If you want to argue this further, then rather than consider what YOU want, please consider what the majority of our users is likely to want, which usually is expected to coincide with what the content creator intended, and which, as backed up by evidence from the millions of sites that do it, I will argue is readability rather than lazy expansion to the maximum browser width. With the large majority of our users not expected to come from mobile (where they can still read our content - scrolling on a smartphone is usually well implemented), I will also argue that making our site more readable for the majority of our users is better than making it more readable for a minority when the experience of the majority is lessened. Now of course, you could easily settle this whole thing by proposing a new patch that does wrapping below a certain column size, and keeps the width above, as this is what I see as the most satisfactory approach. So in effect, my answer to your proposal is: "Good start. We do indeed have a problem for small browser windows, but this patch needs to be improved before I want to integrate it". If you don't want to improve on the patch, which is your choice, that's fine too, but please accept that there might be integration delays then, as I do not see your current proposal as better than what we currently have (which means I don't plan to integrate it), and, unless I'm overruled (which would be a pity since, as the original content creator, I would hope that my intention with regards to how content should be presented to our users has to matter at least a little bit), I or somebody else will therefore have to work on a better proposal that integrates part of your solution. When you submit a patch, and after reviewing it I say that I don't see it good enough for integration and go great lengths to elaborate on the *logical* reasons that make me plan to reject it, then either propose logical counter-arguments on why the reasons for rejection may be wrong and why I should reconsider (I'm afraid the only reason I see for reconsidering is "because it inconveniences *ME*", with the implied justification of assuming that most users will share your views), or propose a better patch that addresses the very reasons for rejection. Or you can try to call for arbitration from the other maintainers, which I don't have a problem with (I'm just a vote here). But then I will also prefer if another maintainer updates the portal content so that I can free up extra time to work on an improved solution. I most certainly hope that at least you don't have an issue with my current proposal of wrapping below a certain size, and setting a max column width above, which I would contend, would satisfactorily solve both our concerns. Regards, /Pete ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
