> Everybody has some little thing they'd like to be able to tweak. And for > many of them, there are two people in the universe that will ever tweak > them. The overwhelming lesson of the data about what options people > actually used that we gathered was that most people customize nothing. > > Don't open Pandora's box. Today it's caret blink rate. What will it be > tomorrow?
+100 --emi ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 14 May 2018 10:07 AM, Tim Boudreau <[email protected]> wrote: > On Mon, May 14, 2018 at 2:15 AM, Christian Lenz [email protected] > > wrote: > > > Of Course, it will increase a bit of the complexity but it is as it is. > > > > This shouldn’t really not a reason why not doing this. > > IMO, maybe it should. From an oldie but a goodie: > > Pull up the Tools | Options dialog box and you will see a history ofarguments > that the software designers had about the design of the product. > > - Joel Spolsky - https://www.joelonsoftware.com/2000/04/12/choices/ > > I was around for the original rewrite of the options window - the > > BeanTreeView with a property sheet that somebody mentioned used to be > > around as the "advanced" view. Now, part of that was the fact that, as we > > learned the hard way with videotaped usability studies, the tree + > property > > sheet interface was completely baffling to a lot of users. But a lot of it > > was the sheer volume of options - who actually wants to customize "Editor > > scroll jump insets"? You could. > > The job, in creating usable software, is to make good choices about > > defaults, so nobody wants to customize them. The way to abdicate that > > responsibility is to avoid choosing "let's make that an option". > > Everybody has some little thing they'd like to be able to tweak. And for > > many of them, there are two people in the universe that will ever tweak > > them. The overwhelming lesson of the data about what options people > > actually used that we gathered was that most people customize nothing. > > Don't open Pandora's box. Today it's caret blink rate. What will it be > > tomorrow? > > If someone simply must have a non-blinking caret, it would be trivial to > > write a plugin that sets that one setting via its layer.xml - and given > > that in 19 years of working on NetBeans or being involved with it, this is > > the only request I have ever seen for that, a downloadable plugin seems > > like the right level of discoverability. People who search the web for > > "netbeans caret blink" will find it, but we don't pollute the UI with a > > setting for something almost nobody on earth is going to care about. > > And I say that, thinking, I'd probably actually like a non-blinking caret > > and install that plugin. But I am also, as one of its developers, not the > > target audience, and what makes me happy can drive others away. > > -Tim > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
