Re: dramantic increases in forced rodent use
John Levon [EMAIL PROTECTED] writes: and for years, people have been forced to go to the manual to work out ^ some how to enter lengths. More recently, we have had a vague help message in some places. Other people have entered length just as they always did. The new interface makes it patently clear what we are expecting, and reduces the potential for user error. ACK. But it does make thing for people who know harder. This is basic good UI design [1] No, absolutely not. A good UI is not only easy but also convenient. This might be a bit hard for a GUI, but it is possible. What about the following idea: You can still enter length as usual, the parser recognises it and sets the drop-down list accordingly. Since the parser did check for correct units, and since the drop-down list is implemented, it should be only a little additional work. And it marks both sides happy. You could also go as far as XEmacs: provide two ways for every option. One keybord based in the status line and one pop-up window for rodent users. But this is of course a lot more work (though it is extremely fast to use). Thomas [EMAIL PROTECTED] -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: dramantic increases in forced rodent use
On 13-Dec-2001 Thomas Steffen wrote: You can still enter length as usual, the parser recognises it and sets the drop-down list accordingly. I think we already somehow decided to adapt this solution (or a similar one which also gives the power to insert stuff like 1cm+2em-4em). Since the parser did check for correct units, and since the drop-down list is implemented, it should be only a little additional work. And it marks both sides happy. Well not only but with the above solution we also need to (de)activate the Ok/Apply buttons and also output an error message why the buttons got disabled, but let's say it's doable with a bit of work. You could also go as far as XEmacs: provide two ways for every option. One keybord based in the status line and one pop-up window for rodent users. But this is of course a lot more work (though it is extremely fast to use). Well we're not that far away from that aproach already now if you know how you can do a lot of things that way (I mean Meta-x command options). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Inspiration without perspiration is usually sterile.
Re: dramantic increases in forced rodent use
John Levon <[EMAIL PROTECTED]> writes: > and for years, people have been forced to go to the manual to work out ^ some > how to enter lengths. More recently, we have had a vague help message > in some places. Other people have entered length just as they always did. > The new interface makes it patently clear what we are expecting, and > reduces the potential for user error. ACK. But it does make thing for "people who know" harder. > This is basic good UI design [1] No, absolutely not. A good UI is not only easy but also convenient. This might be a bit hard for a GUI, but it is possible. What about the following idea: You can still enter length as usual, the parser recognises it and sets the drop-down list accordingly. Since the parser did check for correct units, and since the drop-down list is implemented, it should be only a little additional work. And it marks both sides happy. You could also go as far as XEmacs: provide two ways for every option. One keybord based in the status line and one pop-up window for rodent users. But this is of course a lot more work (though it is extremely fast to use). Thomas <[EMAIL PROTECTED]> -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: dramantic increases in forced rodent use
On 13-Dec-2001 Thomas Steffen wrote: > You can still enter length as usual, the parser recognises it and sets > the drop-down list accordingly. I think we already somehow decided to adapt this solution (or a similar one which also gives the power to insert stuff like 1cm+2em-4em). > Since the parser did check for correct units, and since the drop-down > list is implemented, it should be only a little additional work. And > it marks both sides happy. Well not only but with the above solution we also need to (de)activate the Ok/Apply buttons and also output an error message why the buttons got disabled, but let's say it's doable with a bit of work. > You could also go as far as XEmacs: provide two ways for every option. > One keybord based in the status line and one pop-up window for rodent > users. But this is of course a lot more work (though it is extremely > fast to use). Well we're not that far away from that aproach already now if you know how you can do a lot of things that way (I mean Meta-x command options). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Inspiration without perspiration is usually sterile.
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 12:44:07AM +0100, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] writes: | the problem is that it is taking increasing amounts of user effort to | use lyx, and htis is a trend that has been continuing for some time. I | understand that UI and maintainability are important, but the current | lyx takes a lot more time, activity, and thought by the user than did | the lyx of two years ago. IMHO we have way to few lyxfuncs, you cannot control the layout of a paragraph from the minibuffer, that is one thing I'd like to change. Yes. IMO every dialog should, when OK or Apply has been clicked, call one or several LyXFuncs. So clicking OK in paragraph might trigger: (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) or some rather less verbose equivalent. Then everything is scriptable and key bindable.. Jules
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 08:50:04AM +, Jules Bean wrote: IMO every dialog should, when OK or Apply has been clicked, call one or several LyXFuncs. So clicking OK in paragraph might trigger: (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) or some rather less verbose equivalent. well we should have those (or similar) but I don't think formpara should use them - they would need to redraw on each thing set etc. regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
John == John Levon [EMAIL PROTECTED] writes: but now, the way that used to work, with much less effort, doesn't. John and ? John sorry, the lyx interface is not going to stagnate just because John you like it that way... Could it be that you are a bit grumpy today, John? %-] I'm not sure what a glue lenght is. If it's in/cm/etc., it's the whole point; if not, I have no idea. John I think this is a REALLY good example why we need better John interfaces, thankyou for proving my point succinctly. I'm not so sure about that, in fact. I was actually thinking since a few days about proposing to go back to the good old 1cm text input. Here is why. 1/ what Richark and dochawk said is certainly true. Being forced to use the mouse to enter lengths is not very nice. And even if xforms had keyboard support for choice widgets, it would remain a bit painful (remember you will need a different keyboard accellerator for each choice widget!) 2/ The there is glue. Most people do not know what this is about. But should they? As I see it, people should be first of all encouraged to use symbolic lengths like medskip/bigskip/whatever. This is because (1) they have correct glue and (2) it is the whole point of WYSISWYM vs WYSIWYG. So the cases where people enter explicit lengths is (as far as I can tell) when they need an explicit _fixed_ length. I am not sure that the case where people need 1cm-0.5cm+0.5cm is common enough that we want to design the interface around it. What I am saying basically is that the problem you are trying to solve is real, but the current solution may not be the best. Several things I have been thinking about: 1/ instead of the current 'guess default unit based on paper size' hack, it would be better to let the user choose his default unit in Preferences. 2/ if there is a default unit, we could have a single text entry field where people could enter either '1', '1cm' '1cm+0.5in' or whatever. This is good for power users. 3/ so, how could we help people who are lost with these things. One could have a small button near each length entry field which would open a length picker dialog with lots'o widgets to guide them. What I think is that, like what Larry Wall said about perl 'simple tasks should be easy and difficult tasks should be possible' (or something like that). Having 6 widgets for each glue length value has a price: it takes valuable screen space and confuses the user (in the sense that other things become less visible). So we should not overdo the interface. Feel free to disagree. JMarc
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 10:13:05AM +0100, Jean-Marc Lasgouttes wrote: Could it be that you are a bit grumpy today, John? %-] oh, I admit it ;) I'm not sure what a glue lenght is. If it's in/cm/etc., it's the whole point; if not, I have no idea. John I think this is a REALLY good example why we need better John interfaces, thankyou for proving my point succinctly. I'm not so sure about that, in fact. I was actually thinking since a few days about proposing to go back to the good old 1cm text input. Here is why. 1/ what Richark and dochawk said is certainly true. Being forced to use the mouse to enter lengths is not very nice. And even if xforms had keyboard support for choice widgets, it would remain a bit painful (remember you will need a different keyboard accellerator for each choice widget!) nah, it should be tab navigatable like modern toolkits. even better would have up/down in the text entry switch units. 2/ The there is glue. Most people do not know what this is about. But should they? As I see it, people should be first of all encouraged to use symbolic lengths like medskip/bigskip/whatever. This is because (1) they have correct glue and (2) it is the whole point of WYSISWYM vs WYSIWYG. So the cases where people enter explicit lengths is (as far as I can tell) when they need an explicit _fixed_ length. I am not sure that the case where people need 1cm-0.5cm+0.5cm is common enough that we want to design the interface around it. yes, you're right that the current qt2 solution sucks. I wasn't sure then how much used this feature was by the power users, and how important it was - the answers seem to be : very little, and very little. What I am saying basically is that the problem you are trying to solve is real, but the current solution may not be the best. Sure. 1/ instead of the current 'guess default unit based on paper size' hack, it would be better to let the user choose his default unit in Preferences. 2/ if there is a default unit, we could have a single text entry field where people could enter either '1', '1cm' '1cm+0.5in' or whatever. This is good for power users. mmm. and bad for new lyx users. I come along to a dialog with an extra length and a value. I have NO idea what units this length is in, or how to find out - little do I know there is a default. So we need at least immediate visual feedback ... 3/ so, how could we help people who are lost with these things. One could have a small button near each length entry field which would open a length picker dialog with lots'o widgets to guide them. ... and plus this, would be good. Sounds like a Juergen S thing to me :)) What I think is that, like what Larry Wall said about perl 'simple tasks should be easy and difficult tasks should be possible' (or something like that). Having 6 widgets for each glue length value has a price: it takes valuable screen space and confuses the user (in the sense that other things become less visible). So we should not overdo the interface. yes, that was sucky ... (but not really what I was on about anyway ;) regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 10:17:16AM +0100, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Wed, Dec 12, 2001 at 08:50:04AM +, Jules Bean wrote: IMO every dialog should, when OK or Apply has been clicked, call one or several LyXFuncs. So clicking OK in paragraph might trigger: (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) or some rather less verbose equivalent. | well we should have those (or similar) but I don't think formpara | should use them - they would need to redraw on each thing set etc. Well... I really think the dialogs should use lyxfuncs directly. _but_ we could add a transaction-begin transaction-end lyxfunc, so that several lyxfuncs could be grouped and lyx would not do the stuff until transaction ends. Or just allow lyxfunc grouping. In emacs, it would look something like this: ( (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) ) and lyx knows not to do any screen updates until I gets to the end of the (compound) command. I recall sequences of commands like this being discussed a while back and people didn't like them, though.. Jules
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:19:35AM +, Jules Bean wrote: Or just allow lyxfunc grouping. In emacs, it would look something like this: ( (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) ) and lyx knows not to do any screen updates until I gets to the end of the (compound) command. I recall sequences of commands like this being discussed a while back and people didn't like them, though.. I don't see why not. It would also extend naturally to supporting (lyx-define-macro enter-something ( ...) ) :) regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:22:40AM +, John Levon wrote: On Wed, Dec 12, 2001 at 09:19:35AM +, Jules Bean wrote: Or just allow lyxfunc grouping. In emacs, it would look something like this: ( (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) ) and lyx knows not to do any screen updates until I gets to the end of the (compound) command. I recall sequences of commands like this being discussed a while back and people didn't like them, though.. I don't see why not. It would also extend naturally to supporting (lyx-define-macro enter-something ( ...) ) And the .bind files could bind keys to command sequences, not just atomic commands. IMO a big win. Jules
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:25:07AM +, Jules Bean wrote: And the .bind files could bind keys to command sequences, not just atomic commands. They can partially already by using the 'command-sequence' hack... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: dramantic increases in forced rodent use
Jean-Marc Lasgouttes wrote: John ... and plus this, would be good. Sounds like a Juergen S thing John to me :)) I think JUergen mentionned it is over his competences. But all he needs is a gently push :) There is probably a nasty signal/slot problem to solve here. What would be nice is to have the text fiald open like a kind of combox, but it seems too complicated. It is indeed over my competences currently :-( But this is of course no excuse. I have to point out (again) that I had *no* coding background when I startet to hack in LyX. I have learned to deal intuitively with the frontends stuff a little bit and - thanks to your patience - it's getting better day by day. And it's big fun to learn it :-) I would say that such things are done better by others if the stuff has to be done well and quick (especially since my time is limited at the moment). Otherwise I'll be happy to learn and help where I can. Regards, Juergen. JMarc
Re: dramantic increases in forced rodent use
Jean-Marc Lasgouttes wrote: 1/ what Richark and dochawk said is certainly true. Being forced to use the mouse to enter lengths is not very nice. And even if xforms had keyboard support for choice widgets, it would remain a bit painful (remember you will need a different keyboard accellerator for each choice widget!) I take this point. Even if I have introduced some of the new GUI stuff I see the limits (now). 2/ The there is glue. Most people do not know what this is about. But should they? As I see it, people should be first of all encouraged to use symbolic lengths like medskip/bigskip/whatever. This is because (1) they have correct glue and (2) it is the whole point of WYSISWYM vs WYSIWYG. So the cases where people enter explicit lengths is (as far as I can tell) when they need an explicit _fixed_ length. I am not sure that the case where people need 1cm-0.5cm+0.5cm is common enough that we want to design the interface around it. Probably. But we have to support it in any way. So if we don't use a GUI (like in QT2 or my local XForms), we cannot use a simple length-unit method. A possibility would be something like this: length: ___ [unit choice] extra value: ___ (where the advanced user can insert +2cm-3in) similar to the tabular GUI (with the LaTeX command width field). What I am saying basically is that the problem you are trying to solve is real, but the current solution may not be the best. Several things I have been thinking about: 1/ instead of the current 'guess default unit based on paper size' hack, it would be better to let the user choose his default unit in Preferences. A good idea certainly! 2/ if there is a default unit, we could have a single text entry field where people could enter either '1', '1cm' '1cm+0.5in' or whatever. This is good for power users. 3/ so, how could we help people who are lost with these things. One could have a small button near each length entry field which would open a length picker dialog with lots'o widgets to guide them. An alternative (if this is possible): Use length field and unit choice as is, but allow inserting values like 2cm in the length field (as it used to be). When the user applies such a value, LyX sets the length correctly, inserts the length in the field and sets the choice. IMHO this is not difficult, since it is the way we read old files (and the length strings). All we have to do is to remove (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter from 1.1.6 What I think is that, like what Larry Wall said about perl 'simple tasks should be easy and difficult tasks should be possible' (or something like that). Having 6 widgets for each glue length value has a price: it takes valuable screen space and confuses the user (in the sense that other things become less visible). So we should not overdo the interface. Agreed. We should not overdo it. But we should give normal users hints what to do. Actually, I have missed a lot of possibilities in the 1.1.6 dialogs because I simply didn't know about them. So we have to discuss the pros and cons in any case. Juergen. Feel free to disagree. JMarc
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:20:56AM +, John Levon wrote: nah, it should be tab navigatable like modern toolkits. even better would have up/down in the text entry switch units. Just for the record: How difficult would it be to switch over to some other toolkit _right now_? I am not proposing to do such a thing or even to discuss it, I'd just like to get some idea of the amount of work involved. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: dramantic increases in forced rodent use
Juergen Spitzmueller wrote: An alternative (if this is possible): Use length field and unit choice as is, but allow inserting values like 2cm in the length field (as it used to be). When the user applies such a value, LyX sets the length correctly, inserts the length in the field and sets the choice. IMHO this is not difficult, since it is the way we read old files (and the length strings). All we have to do is to remove (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter from 1.1.6 One problem is probably that we have to filter out the unit-from-choice value in this case. If someone inserts 2in into the input field and the choice is on cm, it will be applied as 2incm, which is bogus of course. Juergen.
Re: dramantic increases in forced rodent use
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Juergen Spitzmueller wrote: An alternative (if this is possible): Use length field and unit choice as is, but allow inserting values like 2cm in the length field (as it used to be). When the user applies such a value, LyX sets the length correctly, inserts the length in the field and sets the choice. IMHO this is not difficult, since it is the way we read old files (and the length strings). All we have to do is to remove (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter from 1.1.6 Juergen One problem is probably that we have to filter out the Juergen unit-from-choice value in this case. If someone inserts 2in Juergen into the input field and the choice is on cm, it will be Juergen applied as 2incm, which is bogus of course. Exactly, but it should not be too difficult. JMarc
Re: dramantic increases in forced rodent use
On 12-Dec-2001 Juergen Spitzmueller wrote: Juergen Spitzmueller wrote: An alternative (if this is possible): Use length field and unit choice as is, but allow inserting values like 2cm in the length field (as it used to be). When the user applies such a value, LyX sets the length correctly, inserts the length in the field and sets the choice. IMHO this is not difficult, since it is the way we read old files (and the length strings). All we have to do is to remove (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter from 1.1.6 One problem is probably that we have to filter out the unit-from-choice value in this case. If someone inserts 2in into the input field and the choice is on cm, it will be applied as 2incm, which is bogus of course. No I meant it as you meant it in your former mail. Actually your proposal of an extra input field is much better than my STR proposal. So I would agree completely with your proposal :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I took a fish head to the movies and I didn't have to pay. -- Fish Heads, Saturday Night Live, 1977.
Re: dramantic increases in forced rodent use
Jean-Marc Lasgouttes wrote: Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Juergen Spitzmueller wrote: An alternative (if this is possible): Use length field and unit choice as is, but allow inserting values like 2cm in the length field (as it used to be). When the user applies such a value, LyX sets the length correctly, inserts the length in the field and sets the choice. IMHO this is not difficult, since it is the way we read old files (and the length strings). All we have to do is to remove (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter from 1.1.6 Juergen One problem is probably that we have to filter out the Juergen unit-from-choice value in this case. If someone inserts 2in Juergen into the input field and the choice is on cm, it will be Juergen applied as 2incm, which is bogus of course. Exactly, but it should not be too difficult. So, shall I have a go on this? I will probably need some help (especially with filtering out the unit-from-choice and the stretch/shrink-values), but I can do at least the first steps. Would this be ok? (example Paragraph): [VSpace: Length] above: [input field] [value choice] (allow GlueLengths) Stretch/Shrink: [input field] etc. I will do this for all other dialogs too (Document-Paper, Minipage, Tabular, Graphics AFAIR) I will try to add a new lyxrc-value for the unit choice in preferences, too as suggested by JMarc. Comments? Juergen. JMarc
Re: dramantic increases in forced rodent use
On Wednesday 12 December 2001 2:42 pm, Andre Poenitz wrote: On Wed, Dec 12, 2001 at 09:20:56AM +, John Levon wrote: nah, it should be tab navigatable like modern toolkits. even better would have up/down in the text entry switch units. Just for the record: How difficult would it be to switch over to some other toolkit _right now_? I am not proposing to do such a thing or even to discuss it, I'd just like to get some idea of the amount of work involved. Andre' Pretty well all the dialogs have been ported behind the frontends firewall. Of these, most have undergone the controller/view split meaning that it's easy to port that dialog to another GUI. The ones that still need this split are the document, maths panel, paragraph, preferences and tabular dialogs. I think we decided that the maths panel should really become a toolbar. I have some code in my tree that started that off. The dialogs that haven't been taken out of the LyX core are the Sendto dialog (custom export) because only Jürgen seems to want it and the figure form for the old figinset. One or two little bits of cruft remain in lyx_gui_misc.C The menu (and toolbar?) code was ported to Qt2 but Kalle complained that that was a horrible process. It needs cleaning up and probably MVC-ing. I started off down this route at some point and could resurrect it fairly quickly. The minibuffer, work-area and the main window all need some work but probably not much. I don't think that anyone's really put much thought into porting the lyxserver. So, to answer your question, it wouldn't be very difficult to hack it over and I don't think it's going to be that hard to do it right either. Angus grep -n FORMS_H_LOCATION *.[Ch] */*.[Ch] LyXSendto.C:3:#include FORMS_H_LOCATION WorkArea.h:23:#include FORMS_H_LOCATION XFormsView.h:20:#include FORMS_H_LOCATION config.h:110:#define FORMS_H_LOCATION forms.h figureForm.C:18:#include FORMS_H_LOCATION figure_form.C:9:#include FORMS_H_LOCATION lyx_gui.C:20:#include FORMS_H_LOCATION lyx_gui_misc.C:17:#include FORMS_H_LOCATION lyx_gui_misc.h:21:#include FORMS_H_LOCATION lyxserver.C:44:#include FORMS_H_LOCATION minibuffer.h:8:#include FORMS_H_LOCATION print_form.C:9:#include FORMS_H_LOCATION insets/figinset.C:42:#include FORMS_H_LOCATION
Re: dramantic increases in forced rodent use
[EMAIL PROTECTED] wrote: My assumption would be that if it is a number, the existing units are used. If not, it would be parsed, and the units changed. This is like I want it to behave too. I will have a look if and how this can be done. Juergen. hakw
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 12:44:07AM +0100, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] writes: > > | the problem is that it is taking increasing amounts of user effort to > | use lyx, and htis is a trend that has been continuing for some time. I > | understand that UI and maintainability are important, but the current > | lyx takes a lot more time, activity, and thought by the user than did > | the lyx of two years ago. > > IMHO we have way to few lyxfuncs, you cannot control the layout of a > paragraph from the minibuffer, that is one thing I'd like to change. Yes. IMO every dialog should, when OK or Apply has been clicked, call one or several LyXFuncs. So clicking OK in paragraph might trigger: (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) or some rather less verbose equivalent. Then everything is scriptable and key bindable.. Jules
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 08:50:04AM +, Jules Bean wrote: > IMO every dialog should, when OK or Apply has been clicked, call > one or several LyXFuncs. > > So clicking OK in paragraph might trigger: > > (paragraph-general-set-alignment left) > (paragraph-general-set-pagebreaks above) > > or some rather less verbose equivalent. well we should have those (or similar) but I don't think formpara should use them - they would need to redraw on each thing set etc. regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
> "John" == John Levon <[EMAIL PROTECTED]> writes: >> but now, the way that used to work, with much less effort, doesn't. John> and ? John> sorry, the lyx interface is not going to stagnate just because John> you like it that way... Could it be that you are a bit grumpy today, John? %-] >> I'm not sure what a glue lenght is. If it's in/cm/etc., it's the >> whole point; if not, I have no idea. John> I think this is a REALLY good example why we need better John> interfaces, thankyou for proving my point succinctly. I'm not so sure about that, in fact. I was actually thinking since a few days about proposing to go back to the good old "1cm" text input. Here is why. 1/ what Richark and dochawk said is certainly true. Being forced to use the mouse to enter lengths is not very nice. And even if xforms had keyboard support for choice widgets, it would remain a bit painful (remember you will need a different keyboard accellerator for each choice widget!) 2/ The there is glue. Most people do not know what this is about. But should they? As I see it, people should be first of all encouraged to use symbolic lengths like medskip/bigskip/whatever. This is because (1) they have correct glue and (2) it is the whole point of WYSISWYM vs WYSIWYG. So the cases where people enter explicit lengths is (as far as I can tell) when they need an explicit _fixed_ length. I am not sure that the case where people need 1cm-0.5cm+0.5cm is common enough that we want to design the interface around it. What I am saying basically is that the problem you are trying to solve is real, but the current solution may not be the best. Several things I have been thinking about: 1/ instead of the current 'guess default unit based on paper size' hack, it would be better to let the user choose his default unit in Preferences. 2/ if there is a default unit, we could have a single text entry field where people could enter either '1', '1cm' '1cm+0.5in' or whatever. This is good for power users. 3/ so, how could we help people who are lost with these things. One could have a small button near each length entry field which would open a length picker dialog with lots'o widgets to guide them. What I think is that, like what Larry Wall said about perl 'simple tasks should be easy and difficult tasks should be possible' (or something like that). Having 6 widgets for each glue length value has a price: it takes valuable screen space and confuses the user (in the sense that other things become less visible). So we should not overdo the interface. Feel free to disagree. JMarc
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 10:13:05AM +0100, Jean-Marc Lasgouttes wrote: > Could it be that you are a bit grumpy today, John? %-] oh, I admit it ;) > >> I'm not sure what a glue lenght is. If it's in/cm/etc., it's the > >> whole point; if not, I have no idea. > > John> I think this is a REALLY good example why we need better > John> interfaces, thankyou for proving my point succinctly. > > I'm not so sure about that, in fact. I was actually thinking since a > few days about proposing to go back to the good old "1cm" text input. > Here is why. > > 1/ what Richark and dochawk said is certainly true. Being forced to > use the mouse to enter lengths is not very nice. And even if xforms > had keyboard support for choice widgets, it would remain a bit painful > (remember you will need a different keyboard accellerator for each > choice widget!) nah, it should be tab navigatable like modern toolkits. even better would have up/down in the text entry switch units. > 2/ The there is glue. Most people do not know what this is about. But > should they? As I see it, people should be first of all encouraged to > use symbolic lengths like medskip/bigskip/whatever. This is because > (1) they have correct glue and (2) it is the whole point of WYSISWYM > vs WYSIWYG. So the cases where people enter explicit lengths is (as > far as I can tell) when they need an explicit _fixed_ length. I am not > sure that the case where people need 1cm-0.5cm+0.5cm is common enough > that we want to design the interface around it. yes, you're right that the current qt2 solution sucks. I wasn't sure then how much used this feature was by the power users, and how important it was - the answers seem to be : very little, and very little. > What I am saying basically is that the problem you are trying to solve > is real, but the current solution may not be the best. Sure. > 1/ instead of the current 'guess default unit based on paper size' > hack, it would be better to let the user choose his default unit in > Preferences. > > 2/ if there is a default unit, we could have a single text entry field > where people could enter either '1', '1cm' '1cm+0.5in' or whatever. > This is good for power users. mmm. and bad for new lyx users. I come along to a dialog with an "extra length" and a value. I have NO idea what units this length is in, or how to find out - little do I know there is a default. So we need at least immediate visual feedback ... > 3/ so, how could we help people who are lost with these things. One > could have a small button near each length entry field which would > open a length picker dialog with lots'o widgets to guide them. ... and plus this, would be good. Sounds like a Juergen S thing to me :)) > What I think is that, like what Larry Wall said about perl 'simple > tasks should be easy and difficult tasks should be possible' (or > something like that). Having 6 widgets for each glue length value has > a price: it takes valuable screen space and confuses the user (in the > sense that other things become less visible). So we should not overdo > the interface. yes, that was sucky ... (but not really what I was on about anyway ;) regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 10:17:16AM +0100, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Wed, Dec 12, 2001 at 08:50:04AM +, Jules Bean wrote: > > > >> IMO every dialog should, when OK or Apply has been clicked, call > >> one or several LyXFuncs. > >> > >> So clicking OK in paragraph might trigger: > >> > >> (paragraph-general-set-alignment left) > >> (paragraph-general-set-pagebreaks above) > >> > >> or some rather less verbose equivalent. > > > | well we should have those (or similar) but I don't think formpara > | should use them - they would need to redraw on each thing set etc. > > Well... I really think the dialogs should use lyxfuncs directly. _but_ > we could add a "transaction-begin" "transaction-end" lyxfunc, so that > several lyxfuncs could be grouped and lyx would not "do the stuff" > until transaction ends. Or just allow lyxfunc grouping. In emacs, it would look something like this: ( (paragraph-general-set-alignment left) (paragraph-general-set-pagebreaks above) ) and lyx knows not to do any screen updates until I gets to the end of the (compound) command. I recall sequences of commands like this being discussed a while back and people didn't like them, though.. Jules
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:19:35AM +, Jules Bean wrote: > Or just allow lyxfunc grouping. In emacs, it would look something > like this: > > ( (paragraph-general-set-alignment left) > (paragraph-general-set-pagebreaks above) ) > > and lyx knows not to do any screen updates until I gets to the end of > the (compound) command. > > I recall sequences of commands like this being discussed a while back > and people didn't like them, though.. I don't see why not. It would also extend naturally to supporting (lyx-define-macro enter-something ( ...) ) :) regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:22:40AM +, John Levon wrote: > On Wed, Dec 12, 2001 at 09:19:35AM +, Jules Bean wrote: > > > Or just allow lyxfunc grouping. In emacs, it would look something > > like this: > > > > ( (paragraph-general-set-alignment left) > > (paragraph-general-set-pagebreaks above) ) > > > > and lyx knows not to do any screen updates until I gets to the end of > > the (compound) command. > > > > I recall sequences of commands like this being discussed a while back > > and people didn't like them, though.. > > I don't see why not. It would also extend naturally to supporting > > (lyx-define-macro enter-something ( ...) ) And the .bind files could bind keys to command sequences, not just atomic commands. IMO a big win. Jules
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:25:07AM +, Jules Bean wrote: > And the .bind files could bind keys to command sequences, not just > atomic commands. They can partially already by using the 'command-sequence' hack... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: dramantic increases in forced rodent use
Jean-Marc Lasgouttes wrote: > John> ... and plus this, would be good. Sounds like a Juergen S thing > John> to me :)) > > I think JUergen mentionned it is over his competences. But all he > needs is a gently push :) There is probably a nasty signal/slot > problem to solve here. What would be nice is to have the text fiald > open like a kind of combox, but it seems too complicated. It is indeed over my competences currently :-( But this is of course no excuse. I have to point out (again) that I had *no* coding background when I startet to hack in LyX. I have learned to deal intuitively with the frontends stuff a little bit and - thanks to your patience - it's getting better day by day. And it's big fun to learn it :-) I would say that such things are done better by others if the stuff has to be done well and quick (especially since my time is limited at the moment). Otherwise I'll be happy to learn and help where I can. Regards, Juergen. > JMarc
Re: dramantic increases in forced rodent use
Jean-Marc Lasgouttes wrote: > 1/ what Richark and dochawk said is certainly true. Being forced to > use the mouse to enter lengths is not very nice. And even if xforms > had keyboard support for choice widgets, it would remain a bit > painful (remember you will need a different keyboard accellerator for > each choice widget!) I take this point. Even if I have introduced some of the new GUI stuff I see the limits (now). > 2/ The there is glue. Most people do not know what this is about. But > should they? As I see it, people should be first of all encouraged to > use symbolic lengths like medskip/bigskip/whatever. This is because > (1) they have correct glue and (2) it is the whole point of WYSISWYM > vs WYSIWYG. So the cases where people enter explicit lengths is (as > far as I can tell) when they need an explicit _fixed_ length. I am > not sure that the case where people need 1cm-0.5cm+0.5cm is common > enough that we want to design the interface around it. Probably. But we have to support it in any way. So if we don't use a GUI (like in QT2 or my local XForms), we cannot use a simple length-unit method. A possibility would be something like this: length: ___ [unit choice] extra value: ___ (where the advanced user can insert "+2cm-3in") similar to the tabular GUI (with the LaTeX command width field). > What I am saying basically is that the problem you are trying to > solve is real, but the current solution may not be the best. > > Several things I have been thinking about: > > 1/ instead of the current 'guess default unit based on paper size' > hack, it would be better to let the user choose his default unit in > Preferences. A good idea certainly! > 2/ if there is a default unit, we could have a single text entry > field where people could enter either '1', '1cm' '1cm+0.5in' or > whatever. This is good for power users. > > 3/ so, how could we help people who are lost with these things. One > could have a small button near each length entry field which would > open a length picker dialog with lots'o widgets to guide them. An alternative (if this is possible): Use length field and unit choice as is, but allow inserting values like "2cm" in the length field (as it used to be). When the user applies such a value, LyX sets the length correctly, inserts the length in the field and sets the choice. IMHO this is not difficult, since it is the way we read old files (and the length strings). All we have to do is to remove (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter from 1.1.6 > What I think is that, like what Larry Wall said about perl 'simple > tasks should be easy and difficult tasks should be possible' (or > something like that). Having 6 widgets for each glue length value has > a price: it takes valuable screen space and confuses the user (in the > sense that other things become less visible). So we should not overdo > the interface. Agreed. We should not overdo it. But we should give normal users hints what to do. Actually, I have missed a lot of possibilities in the 1.1.6 dialogs because I simply didn't know about them. So we have to discuss the pros and cons in any case. Juergen. > Feel free to disagree. > > JMarc
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 09:20:56AM +, John Levon wrote: > nah, it should be tab navigatable like modern toolkits. even better > would have up/down in the text entry switch units. Just for the record: How difficult would it be to switch over to some other toolkit _right now_? I am not proposing to do such a thing or even to discuss it, I'd just like to get some idea of the amount of work involved. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: dramantic increases in forced rodent use
Juergen Spitzmueller wrote: > An alternative (if this is possible): > Use length field and unit choice as is, but allow inserting values > like "2cm" in the length field (as it used to be). When the user > applies such a value, LyX sets the length correctly, inserts the > length in the field and sets the choice. > IMHO this is not difficult, since it is the way we read old files > (and the length strings). All we have to do is to remove > (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter > from 1.1.6 One problem is probably that we have to filter out the unit-from-choice value in this case. If someone inserts "2in" into the input field and the choice is on "cm", it will be applied as "2incm", which is bogus of course. Juergen.
Re: dramantic increases in forced rodent use
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Juergen Spitzmueller wrote: >> An alternative (if this is possible): Use length field and unit >> choice as is, but allow inserting values like "2cm" in the length >> field (as it used to be). When the user applies such a value, LyX >> sets the length correctly, inserts the length in the field and sets >> the choice. IMHO this is not difficult, since it is the way we read >> old files (and the length strings). All we have to do is to remove >> (unsigned)_float_filter and reintroduce isValidGlueLength (?) >> filter from 1.1.6 Juergen> One problem is probably that we have to filter out the Juergen> unit-from-choice value in this case. If someone inserts "2in" Juergen> into the input field and the choice is on "cm", it will be Juergen> applied as "2incm", which is bogus of course. Exactly, but it should not be too difficult. JMarc
Re: dramantic increases in forced rodent use
On 12-Dec-2001 Juergen Spitzmueller wrote: > Juergen Spitzmueller wrote: >> An alternative (if this is possible): >> Use length field and unit choice as is, but allow inserting values >> like "2cm" in the length field (as it used to be). When the user >> applies such a value, LyX sets the length correctly, inserts the >> length in the field and sets the choice. >> IMHO this is not difficult, since it is the way we read old files >> (and the length strings). All we have to do is to remove >> (unsigned)_float_filter and reintroduce isValidGlueLength (?) filter >> from 1.1.6 > > One problem is probably that we have to filter out the unit-from-choice > value in this case. If someone inserts "2in" into the input field and > the choice is on "cm", it will be applied as "2incm", which is bogus of > course. No I meant it as you meant it in your former mail. Actually your proposal of an extra input field is much better than my "STR" proposal. So I would agree completely with your proposal :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I took a fish head to the movies and I didn't have to pay. -- Fish Heads, Saturday Night Live, 1977.
Re: dramantic increases in forced rodent use
Jean-Marc Lasgouttes wrote: > > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> > > writes: > > Juergen> Juergen Spitzmueller wrote: > >> An alternative (if this is possible): Use length field and unit > >> choice as is, but allow inserting values like "2cm" in the length > >> field (as it used to be). When the user applies such a value, LyX > >> sets the length correctly, inserts the length in the field and > >> sets the choice. IMHO this is not difficult, since it is the way > >> we read old files (and the length strings). All we have to do is > >> to remove (unsigned)_float_filter and reintroduce > >> isValidGlueLength (?) filter from 1.1.6 > > Juergen> One problem is probably that we have to filter out the > Juergen> unit-from-choice value in this case. If someone inserts > "2in" Juergen> into the input field and the choice is on "cm", it > will be Juergen> applied as "2incm", which is bogus of course. > > Exactly, but it should not be too difficult. So, shall I have a go on this? I will probably need some help (especially with filtering out the unit-from-choice and the stretch/shrink-values), but I can do at least the first steps. Would this be ok? (example Paragraph): [VSpace: Length] above: [input field] [value choice] (allow GlueLengths) Stretch/Shrink: [input field] etc. I will do this for all other dialogs too (Document->Paper, Minipage, Tabular, Graphics AFAIR) I will try to add a new lyxrc-value for the unit choice in preferences, too as suggested by JMarc. Comments? Juergen. > JMarc
Re: dramantic increases in forced rodent use
On Wednesday 12 December 2001 2:42 pm, Andre Poenitz wrote: > On Wed, Dec 12, 2001 at 09:20:56AM +, John Levon wrote: > > nah, it should be tab navigatable like modern toolkits. even better > > would have up/down in the text entry switch units. > > Just for the record: How difficult would it be to switch over to some other > toolkit _right now_? > > I am not proposing to do such a thing or even to discuss it, I'd just > like to get some idea of the amount of work involved. > > Andre' Pretty well all the dialogs have been ported behind the frontends firewall. Of these, most have undergone the controller/view split meaning that it's easy to port that dialog to another GUI. The ones that still need this split are the document, maths panel, paragraph, preferences and tabular dialogs. I think we decided that the maths panel should really become a toolbar. I have some code in my tree that started that off. The dialogs that haven't been taken out of the LyX core are the Sendto dialog (custom export) because only Jürgen seems to want it and the figure form for the old figinset. One or two little bits of cruft remain in lyx_gui_misc.C The menu (and toolbar?) code was ported to Qt2 but Kalle complained that that was a horrible process. It needs cleaning up and probably MVC-ing. I started off down this route at some point and could resurrect it fairly quickly. The minibuffer, work-area and the main window all need some work but probably not much. I don't think that anyone's really put much thought into porting the lyxserver. So, to answer your question, it wouldn't be very difficult to hack it over and I don't think it's going to be that hard to do it right either. Angus grep -n FORMS_H_LOCATION *.[Ch] */*.[Ch] LyXSendto.C:3:#include FORMS_H_LOCATION WorkArea.h:23:#include FORMS_H_LOCATION XFormsView.h:20:#include FORMS_H_LOCATION config.h:110:#define FORMS_H_LOCATION figureForm.C:18:#include FORMS_H_LOCATION figure_form.C:9:#include FORMS_H_LOCATION lyx_gui.C:20:#include FORMS_H_LOCATION lyx_gui_misc.C:17:#include FORMS_H_LOCATION lyx_gui_misc.h:21:#include FORMS_H_LOCATION lyxserver.C:44:#include FORMS_H_LOCATION minibuffer.h:8:#include FORMS_H_LOCATION print_form.C:9:#include FORMS_H_LOCATION insets/figinset.C:42:#include FORMS_H_LOCATION
Re: dramantic increases in forced rodent use
[EMAIL PROTECTED] wrote: > My assumption would be that if it is a number, the existing units are > used. If not, it would be parsed, and the units changed. This is like I want it to behave too. I will have a look if and how this can be done. Juergen. > hakw
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 12:44:43PM -0500, Richard E. Hawkins wrote: I understand that many people prefer the mouse, but the interface is becoming increasingly awkward to those of us that prefer the keyboard. this is, in essence, an xforms bug as its keyboard navigation support is not good. I refuse to obfuscate the interface for the benefit of a broken toolkit ... regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 02:36:55PM -0500, [EMAIL PROTECTED] wrote: I don't see why this one is xforms. Foryears, we've been able to enter, .5in, and have the program behave sensibly. It seems to me that this should still be parsed and the appropriate settings made. and for years, people have been forced to go to the manual to work out how to enter lengths. More recently, we have had a vague help message in some places. The new interface makes it patently clear what we are expecting, and reduces the potential for user error. This is basic good UI design [1] regards john [1] that we don't allow glue lengths currently in some places we should is under discussion, and irrelevant to this discussion. -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 03:30:50PM -0500, [EMAIL PROTECTED] wrote: and for years, people have been forced to go to the manual to work out how to enter lengths. More recently, we have had a vague help message in some places. but now, the way that used to work, with much less effort, doesn't. and ? sorry, the lyx interface is not going to stagnate just because you like it that way... [1] that we don't allow glue lengths currently in some places we should is under discussion, and irrelevant to this discussion. I'm not sure what a glue lenght is. If it's in/cm/etc., it's the whole point; if not, I have no idea. I think this is a REALLY good example why we need better interfaces, thankyou for proving my point succinctly. the problem is that it is taking increasing amounts of user effort to use lyx I am sorry, that's rubbish. But it is not Friday so I will add : IMHO regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 10:00:43PM -0400, Garst R. Reese wrote: To this I would like add, as a reminder that there are blind computer users, that the mouse for them is as useless as the GUI. http://www.trolltech.com/developer/changes/3.0.0.html http://developer.gnome.org/projects/gap/GNOME-Accessibility.html http://accessibility.kde.org/ You are welcome to hire an accessibility expert to finish Qt accessibility support, and to audit lyx ... john, in a friday mood anyway -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 10:22:15PM -0400, Garst R. Reese wrote: John, I know the issues and problems of accessibility. I'm sure that you know that a key component is having everything accessible via key-strokes. Richard reminded you of that and you replied the good GUI design foremost. I've just shown you several links that suggest GUIs and accessibility are not inimiical to each other - why do you persist in saying otherwise ? Unlike most users, blind programmers go to the extreme of translating docs to braille, and reading them. Richard pointed out that LyX has taken a step backward in accessibility. Richard is not talking about accessibility. He is talking about keyboard interaction, and that is an xforms bug. Is it really that hard to allow users to enter -12bp and let that override the cute GUI cm? no, but it is stupid. Like Lars has already pointed out, such users should be using the minibuffer. The fact that minibuffer support is not complete is a lyxfunc bug. Either way it has nothing to do with the new GUI changes. Read Explorable interfaces and Learnability here : http://www.asktog.com/basics/firstPrinciples.html regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 02:18:17AM -0400, Garst R. Reese wrote: I've just shown you several links that suggest GUIs and accessibility are not inimiical to each other - why do you persist in saying otherwise ? I did not say that. In the words of your Gnome reference: 2.A large class of users with physical disabilities as well as blind users and other groups, need to have full keyboard access to all applications (with no functions available only via the mouse). Note that many power-users are also well served by this functionality and an accessible toolkit indeed supports this. I can navigate to the combo easily using a keyboard in Qt. Richard complained about not having keyboard access that used to be available. see power-users above. I've already said it is a lyxfunc/minibuffer bug ... jeez no, but it is stupid. Like Lars has already pointed out, such users should be using the minibuffer. The fact that minibuffer support is not complete is a lyxfunc bug. Either way it has nothing to do with the new GUI changes. The truth is that they will probably stick with LaTeX, and enjoy a maxi-buffer. and ? lyx tries its best to cater for a wide range of users, and NO HARDER. You can only please most people most of the time. I'm not going to back out a useful clarification of the accepted input for the benefit of one user, sorry. Read Explorable interfaces and Learnability here : http://www.asktog.com/basics/firstPrinciples.html I did not find anything relevant in that one. ummm ... anyway,this is wasting bug fixing bandwidth ... regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, 12 Dec 2001, John Levon wrote: Richard is not talking about accessibility. He is talking about keyboard interaction, and that is an xforms bug. John, with all respect: Rule number one in usability is to listen to the users. Traditionally, LyX has gone to great lengths to work around XForms bugs. I see little good reason to give up that tradition. After all, the XForms code is split into a separate compartment these days, so it should be maintainable to do this, although it will be ugly. If you do not have time or energy to work on this, just say that. Greets, Asger
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 12:44:43PM -0500, Richard E. Hawkins wrote: > I understand that many people prefer the mouse, but the interface is > becoming increasingly awkward to those of us that prefer the keyboard. this is, in essence, an xforms bug as its keyboard navigation support is not good. I refuse to obfuscate the interface for the benefit of a broken toolkit ... regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 02:36:55PM -0500, [EMAIL PROTECTED] wrote: > I don't see why this one is xforms. Foryears, we've been able to > enter, ".5in", and have the program behave sensibly. It seems to me > that this should still be parsed and the appropriate settings made. and for years, people have been forced to go to the manual to work out how to enter lengths. More recently, we have had a vague help message in some places. The new interface makes it patently clear what we are expecting, and reduces the potential for user error. This is basic good UI design [1] regards john [1] that we don't allow glue lengths currently in some places we should is under discussion, and irrelevant to this discussion. -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 03:30:50PM -0500, [EMAIL PROTECTED] wrote: > > and for years, people have been forced to go to the manual to work out > > how to enter lengths. More recently, we have had a vague help message > > in some places. > > but now, the way that used to work, with much less effort, doesn't. and ? sorry, the lyx interface is not going to stagnate just because you like it that way... > > [1] that we don't allow glue lengths currently in some places we should is under > > discussion, and irrelevant to this discussion. > > I'm not sure what a glue lenght is. If it's in/cm/etc., it's the whole > point; if not, I have no idea. I think this is a REALLY good example why we need better interfaces, thankyou for proving my point succinctly. > the problem is that it is taking increasing amounts of user effort to > use lyx I am sorry, that's rubbish. But it is not Friday so I will add : IMHO regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 10:00:43PM -0400, Garst R. Reese wrote: > To this I would like add, as a reminder that there are blind computer > users, that the mouse for them is as useless as the GUI. http://www.trolltech.com/developer/changes/3.0.0.html http://developer.gnome.org/projects/gap/GNOME-Accessibility.html http://accessibility.kde.org/ You are welcome to hire an accessibility expert to finish Qt accessibility support, and to audit lyx ... john, in a friday mood anyway -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Tue, Dec 11, 2001 at 10:22:15PM -0400, Garst R. Reese wrote: > John, I know the issues and problems of accessibility. I'm sure that you > know that a key component is having everything accessible via > key-strokes. Richard reminded you of that and you replied the good GUI > design foremost. I've just shown you several links that suggest GUIs and accessibility are not inimiical to each other - why do you persist in saying otherwise ? > Unlike most users, blind programmers go to the extreme > of translating docs to braille, and reading them. Richard pointed out > that LyX has taken a step backward in accessibility. Richard is not talking about accessibility. He is talking about keyboard interaction, and that is an xforms bug. > Is it > really that hard to allow users to enter -12bp and let that override the > cute GUI cm? no, but it is stupid. Like Lars has already pointed out, such users should be using the minibuffer. The fact that minibuffer support is not complete is a lyxfunc bug. Either way it has nothing to do with the new GUI changes. Read "Explorable interfaces" and "Learnability" here : http://www.asktog.com/basics/firstPrinciples.html regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, Dec 12, 2001 at 02:18:17AM -0400, Garst R. Reese wrote: > > I've just shown you several links that suggest GUIs and accessibility are not > > inimiical to each other - why do you persist in saying otherwise ? > I did not say that. In the words of your Gnome reference: > > 2.A large class of users with physical disabilities as well as > blind users and other groups, need to have full keyboard > access to all applications (with no functions available only > via the mouse). Note that many "power-users" are also well > served by this functionality and an accessible toolkit indeed supports this. I can navigate to the combo easily using a keyboard in Qt. > Richard complained about not having keyboard access that used to be > available. see "power-users" above. I've already said it is a lyxfunc/minibuffer bug ... jeez > > no, but it is stupid. Like Lars has already pointed out, such users should be > > using the minibuffer. The fact that minibuffer support is not complete is a > > lyxfunc bug. Either way it has nothing to do with the new GUI changes. > > The truth is that they will probably stick with LaTeX, and enjoy a > maxi-buffer. and ? lyx tries its best to cater for a wide range of users, and NO HARDER. You can only please most people most of the time. I'm not going to back out a useful clarification of the accepted input for the benefit of one user, sorry. > > Read "Explorable interfaces" and "Learnability" here : > > http://www.asktog.com/basics/firstPrinciples.html > > > I did not find anything relevant in that one. ummm ... anyway,this is wasting bug fixing bandwidth ... regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: dramantic increases in forced rodent use
On Wed, 12 Dec 2001, John Levon wrote: > Richard is not talking about accessibility. He is talking about keyboard interaction, > and that is an xforms bug. John, with all respect: Rule number one in usability is to listen to the users. Traditionally, LyX has gone to great lengths to work around XForms bugs. I see little good reason to give up that tradition. After all, the XForms code is split into a separate compartment these days, so it should be maintainable to do this, although it will be ugly. If you do not have time or energy to work on this, just say that. Greets, Asger
