RE: [XaraXtreme-dev] Text on path indents

["Charles Moir" <CharlesM@xxxxxxxx>]

> It's amazing the peculiar habits people get into. See (for 
> instance) the fact that by default the colour editor does not 
> edit in native colour model.

A relatively recent change to try and counter the appalling mess that
colour models bring. Just see the continuous ongoing stream of customer
confusion that the CMYK model brings, to even the most experienced and
"expert" Xara users. 99% of seasoned professional graphics designers
still don't understand any of it. Worse, most of them think they do
understand it.

Off topic I realise, but I know with absolute clarity that we should
remove all but the HSV colour editor, and we'd have a hugely simpler and
better system for the 99% of users who really just want to pick a
colour. They do not want to understand the implications of separations,
colour models, colour spaces, gamut, profiles and all the rest of the
techno-babble that clutters this area.

Defaulting to always showing HSV picker is part of way towards trying to
reduce confusion.

> You yourself often make the 
> argument for not changing UI unless absolutely necessary - 
> surely it's worse to change something and not support the old 
> UI at all?

No I make the argument for not adding to the UI. I'm quite happy to
remove pointless features and we should be doing, throughout Camelot. We
should be constantly struggling to cut, cut and cut more. Simplify,
simplify and then make it simpler still.

(A perfect example, right in this area, is the pointless Auto-kern
button the text tool Infobar. We're going to have a big space issue on
this Infobar soon with new stuff coming down the road. Anyway who has
ever, ever used this feature to not auto-kern text? Why on earth would
you not want auto-kerning. Bad decision making, and a mistake of mine
for allowing it to go in)

I make the argument for not changing things in Xara LX 1.0 for
completely different reasons. (a) All the documentation, manuals, help,
thousands of pages of web tutorial, and movies show the existing UI. We
simply cannot afford to re-do this, from a time or money point of view
in the race to create a "1.0" Linux version. (b) We know it works and we
know just how very costly it can be changing things (think colour edit
changes). Copying something exactly is 10x easier than inventing new
stuff, and it means, just as we've done with this text margins, it's
very easy to find out how it should behave.

So the goal for LX was always 'let's not invent anything or change
anything', which we're now breaking in some minor areas I admit.

But step back, consider the issue here.

A) We have a hugely unintuitive, very confusing, inconsistent feature.
It has a corresponding high support cost. "Why can't I see the margin
blobs, when you can".

B) The suggested solution involves adding or removing no buttons, or
adding any more UI at all. It involves the slight change to the
behaviour of one menu option, so 'Fit text to curve' does the same as
typing on a curve.

That is a huge, no-brainer, gain. This slight change solves the problem
completely. Now you'll always get your margins blobs, the questions will
stop and we have a consistent UI.

The downside is that we lose an obscure feature. Well that's a price
well worth paying. (The logic is: We gets lots of people wondering about
why they can't see margins on their text. We get no one (that I know of)
who uses or will miss the lost feature. So that makes it a very simple
decision)

The solution to the lost feature, adding a new button, is not a price
worth paying in my opinion UNLESS it has some other upside, which it
does. Then it might be worth it. But actually that's a separate point.

We should make the change to the menu - for the reasons listed above.

We can make a further change to add a new feature, and add a new button,
at the same time as restore the lost feature, at a later time.

> And if it's a curve? You need to add a line segment on the end, no?

No. You either just draw on the end of the curve with the freehand tool
or just drag extend the curve. In all the times I've ever had text on a
curve and the curve wasn't long enough, it's been trivial to extend the
curve without adding new segments. I just drag on the end and sometimes
drag on the curve and sometimes adjust the bezier control handle.

> It looks like Phil put the argument more eloquently than me 
> anyway. I agree that it is much more useful to change 
> unwrapped text into wrapped text than vice-versa, but if it's 
> free (given turning unwrapped into wrapped is 
> useful), and it maintains a feature that (the text going 
> beyond the end of a line) which we would not in retrospective 
> have introduced but which now people /may/ rely on, I don't 
> really see it as a bad thing.

Trouble is not free. We have to invent a new feature, the ability to
wrap / unwrap text, add a new button, get a new icon designed, document
the change and test it all.

I have no problem adding this to the long wish list of new features. But
it can't be a priority and should not be tied to the work of fixing the
behaviour of the 'fit text to curve' feature.

> You wouldn't put in a greying 
> action button that just converted it one way, would you?
No way.

Charles