On Fri, Jun 21, 2002 at 01:34:43PM +1000, Allan Rae wrote: > People everywhere are apathetic. They realise that the world changes > from one bad day to the next and there's bugger all they can do about > it and noone listens when they complain anyway. So why bother?
I think you don't have enough faith in the users. Michael Schmitt comes to mind here. > > The real fix for this is a multi-part document outliner. > > So when a multi-part document outliner exists then we can reconsider > removing the option. > No, we shouldn't include crippled "features" that just suck, we should try to do things properly first time round. cf. the recent section short title debates. Otherwise we end up in bug 488 situations where we must maintain by attrition, rather than by design. > Outlining in general would be nice but we don't have this and it seems > many people aren't interested in even considering it. Like who ? But this is offtopic. > > You must admit that without this option you have a simple work around, > > A fucked-up work around. As nzkoz just pointed out to me, M-f n M-f s is scriptable, and easy enough to do, if you really want this bogonised behaviour. That way it's intuitive out of the box, and powerful enough to be bent towards your desiers. Fixing M-x buffer-new blah.lyx to actually work would be even better. > Let's remove search-and-replace because we have a simple workaround > for that too! And don't use that lame useability arguement to defend > keeping search-and-replace because it just won't wash. That > search-and-replace feature complicates the code too much and extends > compile time too! And it uses boost::regex and we all hate that! Hyperbole. search and replace is core functionality, and as such, is essential. Its sucky user interface is a pity, but we have to have /something/ there. What is the "simple workaround" you refer to ? I'm afraid I can't think of one. It wouldn't be hard to pick an example where I wouldn't necessarily agree with you, but had some validity to it. It's a pity you didn't do that. > > so you cannot use a usability argument like this in defence of keeping > > the option, given that a) no other application does anything like this > > (I suppose I am going to get told that emacs or something equally > > screwed up does this) > > Just because Word does it doesn't make it right. Useability this and > useability that... Who is talking about that ratbag of crap Word ? I tried to use Word once, and gave up in ten minutes. Word is actually far worse than LyX in terms of usability (yes, I do mean this). > Different strokes for different folks -- hence vi > and emacs. But we are not vi and emacs, now are we ? We are LyX. That's /one/ application. Every single pref should be strongly justified: and "I haven't time to fix M-x buffer-new" doesn't count, sorry. > You already have it as the freaking default! Now you want > world domination by annihilating your sworn enemies too! I want to simplify and streamline the terrible LyX user interface, just like I want to do to the code. I don't know yet which is harder, but I know trying is fun, for both. > > b) it complicates the code > > Adding the name-when-you-save capability complicated the code. Yes it did. Everything is a trade off. In this case, the benefit of Save As (everything has it, it's intuitive, natural and sensible) is greater than the cost (implementation cost, extra menu item). > > c) it complicates the prefs > > Oh get real. One little check button is complicating the prefs? > What a load of shite. Try a little exercise. Get someone down the corridor who's never used LyX and ask them to turn off LyX keeping backups. One check button is not a problem. We have 26, next to 63 input boxes, and 21 buttons. Some subset of these prefs have genuine usefulness, and should stay. This means we must chip away at the useless ones in an attempt to achieve sanity. To some degree I'm not concerned about the final result of this conversation, since I will not include this option in the Qt version of prefs, and the qt frontend (or gnome) is what the majority of users will be using in two years time. But I'd still like to see it go. > So take the ellipsis off and leave if off see if I care. A user has > to activate the name-when-I-create option anyway so they'll know they > are going to get a dialog because that's what they just set their > preference for. Duh. It's inconsistent. Just because the user asked for it doesn't mean all bets are off, and the presence of absence of an ellipsis becomes meaningless. I had to make a painful change today, where we can still get a dialog on Insert->Index Entry, even though there is no ellipsis. This is inconsistent, but the trade offs involved in the related changes make it worth it. > We have consistancy and conformity but also offer another way. Just > get rid of the ellipsis and noone will be upset except GUI-fetishists > and the anal-retentive menu mafia. More hyperbole. > So which apps are included in your survey of "What > features/capabilities/preferences are acceptable for LyX to offer?" You clearly mis-understand. Consistency with other applications is not the be-all and end-all. However, when we are inconsistent with ALL other applications, we should ask ourselves some hard questions: why are we doing it like this ? is there a strong justification for it ? is the cost of inconsistency offset by the benefit of the UI ? Perhaps you should read this : http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html It's very good. I want you to dis-abuse yourself of this notion that usability is about "dumbing down". It is in fact the exact opposite. regards john -- "If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared." - St. Augustine
