On Wed, Dec 03, 2003 at 05:09:28PM +0100, Andre Poenitz wrote:
> Now, what's the exact difference between C-b and C-b?
>
> I can't follow you here?
Um, we were comparing :
> > > Cut, create new \emph inset, go there, paste.
> > > "select object, apply change"
i.e. inset splitting.
> That's independent of mathed. You predicted an outcry and it simply did
> not happen.
>
> Now you are saying "people won't be happy" again.
>
> How whould you argue in that case and not point back to the preceding
> case?
Sigh, OK.
There are a number of ways in which users can be negatively affected by
a feature. Sometimes these are critical ("LyX crashed"), sometimes
merely very annoying ("LyX has a stupid banner in the way"), and
sometimes marginal ("The insert menu is too big and unwieldy"). These
affect different users in different ways. Some things may not bother
user A at all, but a constant PITA for user B.
So, first, we have only a subset of the total user population U. In
order to get a complaint we have to have a subset of users who are
negatively affected by a feature. Within this subset, we need a further
subset of users who actually consciously notice the negative effect
(research has shown time and time again that users aren't very good at
identifying what causes an increase in time-to-task-completion). Then we
have to find a further subset such that it contains users motivated and
willing to report the problem. This can be constrained by such factors
as :
"the mailing list looks scary"
"I'm too busy"
"I suppose the designers know what they're doing, who am I to disagree?"
"I'm not using the latest LyX, perhaps it's fixed"
"Sod this, I'm going back to scientific word (or whatever)"
"I don't know how to describe my problem well"
"It's not important enough to report"
Taking all the above into consideration, I hope you can see that the
absence of complaints does not imply satisfaction, either conscious or
unconscious. The feedback process is a very lossy one indeed. We simply
CANNOT, as designers, rely on feedback as anything other than one of
several inputs into the design process.
> Start with
>
> s|s
>
> Type <C-e>aaaaa aaaa<C-e>
>
> That's two.
>
> There are a few more variations on that 'feature'.
You won't find me arguing that this stupid "affect the word by default"
thing isn't dumb. But this is trivially fixable, as opposed to the
significant problems of using insets. So it is not an argument against
ranges per se; it's an argument against having this stupid feature.
> > > I don't mind putting this stuf into the edit menu if that helps your
> > > imagination.
> >
> > Then the reverse problem applies.
>
> You are not, by chance, arguing that someone might not find something in
> the menus and will be annoyed by that?
No. I'm arguing that an Edit menu item that inserts some new object is
baffling to the user. The insets are objects to the user; ranges are
not.
> > > > o I can't select part of an inset and part outside of an
> > > > inset and apply a change
> > >
> > > I would argue that this feature is rarely needed.
> >
> > I would argue that I do it regularly. A LOT.
>
> Please give a concrete example.
If I want to expand or decrease a selection, it's often nice to have
some leeway on one end, thus I can select the start of a word, and push
the mouse over to somewhere inside the region, and select Italic, done.
Of course LyX gets this wrong anyway, it decides to flip rather than
just apply. A bug.
> > > However, it is implementable by splitting the insets at the selection
> > > boundary
> >
> > You can't even *make* such a selection !
>
> So how come people don't complain?
If you'll allow me to rephrase this as "Why isn't this currently a
problem?", the answer is because insets currently represent disjoint
parts of a text: footnotes, margin notes, minipages. It thus makes no
sense to able to select across a boundary, because that boundary does
not intersect a region of text as it appears in the output.
> Viewing documents as tree is not the worst approach I've seen.
I didn't say it was the worst. I can certainly construct worse :)
> Bad enough. So these points of your argument are based on some features
> currently available for noun style that you've admittedly never used?
Um, no. I, naturally, have heavily used physical character styles in the
absence of LCS. The thing with Noun is just a testing thing because it's
currently implemented both ways in CVS lyx. I am sure you must be aware
of this and are just being facetious for some reason.
> You could try font changes in mathed which might be a bit smoother to
> handle than a two-week old feature in the outside world.
I can't even unapply a change of some text to bold in mathed without
running round the houses.
> Export is the next one. Then 'it is already there'. Then 'IU'. I think I
^^^^
Bzzt. That's implementation detail. As is "already there", and probably
"Export".
regards
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
