Call for testers: the features/scroll-reloaded branch

[Jean-Marc Lasgouttes]

Hello,

Next on my plate after str-metrics is the GSoC 2013 horizontal scrolling
project.

On this new features/scroll-reloaded branch, I have finished the pending
parts of this work. The only remaining glitch that I know of is
selection with mouse, but there are probably others.

I am open to requests for improvements, although I have to warn that I
am not going to implement a real scrollbar :) Please first try the
keyboard-based interface, I suspect it does the most important part.

JMarc

[Scott Kostyshak]

On Sat, Jul 26, 2014 at 5:20 PM, Jean-Marc Lasgouttes

I am open to requests for improvements, although I have to warn that I am
not going to implement a real scrollbar :) Please first try the
keyboard-based interface, I suspect it does the most important part.

Is Hashini still interested in solving any (hopefully minor) issues
that come up?

It compiles fine for me. If I make a 3x3 table and put the cursor in
the second row, third column, and just hold the key "a" down, I get
the result that is attached (I also add some s's and an "x" at the
end). There are two problems: (1) the four "a"s shown in a cell on the
left make it seem that there is text in more than one cell when in
fact I only entered text in one cell. (2) the cursor should be at the
end (after the "x").

Scott

[Jean-Marc Lasgouttes]

Post by Scott Kostyshak
On Sat, Jul 26, 2014 at 5:20 PM, Jean-Marc Lasgouttes

I am open to requests for improvements, although I have to warn that I am
not going to implement a real scrollbar :) Please first try the
keyboard-based interface, I suspect it does the most important part.

Is Hashini still interested in solving any (hopefully minor) issues
that come up?

I'm not sure. At the end of here GSoC she said she would be interested
continuing, and I gave her a list of useful stuff she could do, and
then, nothing happened...

Post by Scott Kostyshak
It compiles fine for me. If I make a 3x3 table and put the cursor in
the second row, third column, and just hold the key "a" down, I get
the result that is attached (I also add some s's and an "x" at the
end). There are two problems: (1) the four "a"s shown in a cell on the
left make it seem that there is text in more than one cell when in
fact I only entered text in one cell. (2) the cursor should be at the
end (after the "x").

I'll have a look.

JMarc

[Jean-Marc Lasgouttes]

Post by Jean-Marc Lasgouttes
I am open to requests for improvements, although I have to warn that I
am not going to implement a real scrollbar :) Please first try the
keyboard-based interface, I suspect it does the most important part.

As an experiment, there is now a mark on the left or on the right to
indicate that part of the row is hidden. The color is hardcoded to red,
I'll add a new color if this code is kept.

I am interested in 2 types of feedback:
* rendering bugs
* qualitative reports on the user experience.

So, is this code good enough in terms of keyboard-based editing? Does it
solve the problem of too large rows?

So, basically, do you like it?

JMarc

[Scott Kostyshak]

On Sun, Jul 27, 2014 at 1:02 PM, Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes
As an experiment, there is now a mark on the left or on the right to
indicate that part of the row is hidden. The color is hardcoded to red, I'll
add a new color if this code is kept.

I like the idea of having something. I don't think I like having it be
red by default, but I'm not sure.

Post by Jean-Marc Lasgouttes
* rendering bugs
* qualitative reports on the user experience.
So, is this code good enough in terms of keyboard-based editing? Does it
solve the problem of too large rows?

In limited testing, it seems good to me.

Post by Jean-Marc Lasgouttes
So, basically, do you like it?

I do.

Scott

[Jean-Marc Lasgouttes]

Post by Scott Kostyshak
On Sun, Jul 27, 2014 at 1:02 PM, Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes
As an experiment, there is now a mark on the left or on the right to
indicate that part of the row is hidden. The color is hardcoded to red, I'll
add a new color if this code is kept.

I like the idea of having something. I don't think I like having it be
red by default, but I'm not sure.

What color would seem reasonable? I'd like to find one that we already
use, in order to limit the "chrismas tree" effect.

It would be nice if we could reduce the number of colors (at least by
default), but I never had success with that.

JMarc

[Jürgen Spitzmüller]

Post by Jean-Marc Lasgouttes
It would be nice if we could reduce the number of colors (at least by
default), but I never had success with that.

I don't think the number of colors is a problem per se (on the contrary: I
think it's good to make use of them for semantic purposes).

The problem, IMHO, is that we do not use a coherent color scheme (a color
palette).

Jürgen

Post by Jean-Marc Lasgouttes
JMarc

[Jean-Marc Lasgouttes]

Post by Jürgen Spitzmüller

Post by Jean-Marc Lasgouttes
It would be nice if we could reduce the number of colors (at least by
default), but I never had success with that.

I don't think the number of colors is a problem per se (on the contrary: I
think it's good to make use of them for semantic purposes).

We should not rely on colors to convey semantics. That's what UI guides
tend to say, anyway.

JMarc

[Jürgen Spitzmüller]

Post by Jean-Marc Lasgouttes
We should not rely on colors to convey semantics. That's what UI guides
tend to say, anyway.

Really? Note that I am not advocating to use colors alone for semantic
purposes. However, I think that colors can help to memorize semantics (if used
systematically).

Jürgen

Post by Jean-Marc Lasgouttes
JMarc

[Jean-Marc Lasgouttes]

Post by Jürgen Spitzmüller

Post by Jean-Marc Lasgouttes
We should not rely on colors to convey semantics. That's what UI guides
tend to say, anyway.

Really? Note that I am not advocating to use colors alone for semantic
purposes. However, I think that colors can help to memorize semantics (if used
systematically).

To be frank, I tried to find again an authoritative text stating that,
and kind of failed. The consensus, though is that your interface should
make sense in black and white.

JMarc

[Jürgen Spitzmüller]

Post by Jean-Marc Lasgouttes
To be frank, I tried to find again an authoritative text stating that,
and kind of failed. The consensus, though is that your interface should
make sense in black and white.

Well, I can understand that people who cannot distinguish (some) colors should
still be able to make sense of the UI. This is an accessibility issue. But I
fail to see why this should exclude the use of colors to strengthen semantics.
Why cut off a semiotic modality that is used all over the place in visual
communication?

Jürgen

Post by Jean-Marc Lasgouttes
JMarc

[Jean-Marc Lasgouttes]

Post by Jürgen Spitzmüller
Well, I can understand that people who cannot distinguish (some) colors should
still be able to make sense of the UI. This is an accessibility issue. But I
fail to see why this should exclude the use of colors to strengthen semantics.
Why cut off a semiotic modality that is used all over the place in visual
communication?

We agree. "Strengthten" is the key word. We should not rely on it.

Concerning the number of colors, reducing them is IMO a way to improve
semantics. If by using the same color we can indicate that two elements
are in the same family (while their shape indicate what they are), I
think have have stronger semantics.

JMarc

[Jürgen Spitzmüller]

Post by Jean-Marc Lasgouttes
If by using the same color we can indicate that two elements
are in the same family (while their shape indicate what they are), I
think have have stronger semantics.

We agree indeed. This is what I meant with "systematic" (and "semantic, for
that matter). Plus, from an aesthetic POV, if the colors would come from a
well-thought palette, the use of multiple colors would not be that disturbing
(coming back to the "Christmas tree" metaphor).

So, the point is not primarily "reducing" colors, but systematizing their use
and harmonizing their range (which of course could well mean "reducing" in
effect).

Jürgen

Post by Jean-Marc Lasgouttes
JMarc

[Jean-Marc Lasgouttes]

Post by Jürgen Spitzmüller
So, the point is not primarily "reducing" colors, but systematizing their use
and harmonizing their range (which of course could well mean "reducing" in
effect).

And from my previous failed effort, it seems that we cannot afford to
enforce in the code that some things have the same color. This should
probably be done in a color theme. The right to choose random colors is
a bit like the second amendment of the US constitution.

JMarc

[Jürgen Spitzmüller]

Post by Jean-Marc Lasgouttes
And from my previous failed effort, it seems that we cannot afford to
enforce in the code that some things have the same color. This should
probably be done in a color theme. The right to choose random colors is
a bit like the second amendment of the US constitution.

We certainly should enforce color assignment per category (type), not per
thing (token). Theming looks sensible. As a bonus, this wold allow to adjust
the used color palette to the theme to the OS.

For a start, though, we would gain much if we would re-audit our own current
color use.

GSOC idea?

Jürgen

Post by Jean-Marc Lasgouttes
JMarc

[Jean-Marc Lasgouttes]

Post by Jürgen Spitzmüller
We certainly should enforce color assignment per category (type), not per
thing (token).

Good luck with that.

Post by Jürgen Spitzmüller
Theming looks sensible. As a bonus, this wold allow to adjust
the used color palette to the theme to the OS.

One feature that would be useful is to use a color name as value for
another color. Example:

\set_color "background" "white"
\set_color "graphicsbg" "background"
\set_color "mathbg" "background"

Alternatively, we could add possibility to set a color to "none" so that
the element is transparent (only makes sense for background, probably).

With these few tools in place, making a theme would be easier. Of
course, our current color picker does not allow these things.

Post by Jürgen Spitzmüller
For a start, though, we would gain much if we would re-audit our own current
color use.
GSOC idea?

GSoC is for code. Isn't there something related for UI designers?

JMarc

[Cyrille Artho]

Post by Jean-Marc Lasgouttes

Post by Jürgen Spitzmüller
We certainly should enforce color assignment per category (type), not per
thing (token).

Good luck with that.

Post by Jürgen Spitzmüller
Theming looks sensible. As a bonus, this wold allow to adjust
the used color palette to the theme to the OS.

One feature that would be useful is to use a color name as value for
\set_color "background" "white"
\set_color "graphicsbg" "background"
\set_color "mathbg" "background"
Alternatively, we could add possibility to set a color to "none" so that
the element is transparent (only makes sense for background, probably).
With these few tools in place, making a theme would be easier. Of course,
our current color picker does not allow these things.

Post by Jürgen Spitzmüller
For a start, though, we would gain much if we would re-audit our own current
color use.
GSOC idea?

GSoC is for code. Isn't there something related for UI designers?
JMarc

It seems that a systematic use of colors requires many code changes (color
picker, color usage in the code). This in itself is probably best done with
a script that parses most color constants out of the code to get an
overview and organize this.

So we could devise a GSoC project that is mostly code-based, and if someone
gets the framework in place to set color palettes/themes, then producing
eye candy (color themes) is a nice bonus.

[Jean-Marc Lasgouttes]

Post by Cyrille Artho
It seems that a systematic use of colors requires many code changes
(color picker, color usage in the code). This in itself is probably best
done with a script that parses most color constants out of the code to
get an overview and organize this.

Well, the table of colors is already a description in itself. I am not
sure that the changes in code are very important.

Post by Cyrille Artho
So we could devise a GSoC project that is mostly code-based, and if
someone gets the framework in place to set color palettes/themes, then
producing eye candy (color themes) is a nice bonus.

Not just a nice bonus, we need somebody who is competent in this field.
I can recognize a good meal, but I can't cook. We as programmers should
recognize that we do not know how to design. And the LyX interface is a
proof of that.

The ideal situation would be to have a designer who produces mockups and
color theme and then somebody to implement the needed changes.

It would be a good mission for the people who go to the GSoC meeting to
find out whether such a thing can be done :)

JMarc

[Cyrille Artho]

Post by Cyrille Artho
So we could devise a GSoC project that is mostly code-based, and if
someone gets the framework in place to set color palettes/themes, then
producing eye candy (color themes) is a nice bonus.

Not just a nice bonus, we need somebody who is competent in this field. I
can recognize a good meal, but I can't cook. We as programmers should
recognize that we do not know how to design. And the LyX interface is a
proof of that.
The ideal situation would be to have a designer who produces mockups and
color theme and then somebody to implement the needed changes.
It would be a good mission for the people who go to the GSoC meeting to
find out whether such a thing can be done :)
JMarc

That's a good point, but there are some people who are pretty good at both.
I've had a student like that a few years ago.

For a GSoC project, a simple color scheme as proof of concept would
suffice, and we could let others provide more themes/color schemes.

[Scott Kostyshak]

On Mon, Jul 28, 2014 at 3:23 AM, Jean-Marc Lasgouttes

Post by Scott Kostyshak
I like the idea of having something. I don't think I like having it be
red by default, but I'm not sure.

What color would seem reasonable? I'd like to find one that we already use,
in order to limit the "chrismas tree" effect.

Well, my thought was "anything but red". For me, red should be
reserved for something that we think is likely wrong (warning/error).
I think it is a cheap way to draw attention, kind of like how we add
exclamation points in many places. I prefer to save red and
exclamation points for where we really want to get the user's
attention, otherwise they will become desensitized.

I'm trying to think of analog concepts in other applications. In Libre
Office Calc, if you put a long string in one cell, and then in the
next cell to the write you put something (anything), in the first cell
a red arrow is shown.

Do you have UI guides/books that you would recommend for study? I
remember you referenced the Apple UI guide. Would you recommend that
one?

Scott

[Jürgen Spitzmüller]

Post by Scott Kostyshak
Well, my thought was "anything but red". For me, red should be
reserved for something that we think is likely wrong (warning/error).
I think it is a cheap way to draw attention, kind of like how we add
exclamation points in many places. I prefer to save red and
exclamation points for where we really want to get the user's
attention, otherwise they will become desensitized.

I haven't checked which kind of red JMarc used, but in connection to our
discussion today I'd say: use a color that is used to indicate that this is
related to the editor, not the LaTeX output.

The dark red used a.o. for indendation markers seems appropriate, doesn't it?

Jürgen

[Jean-Marc Lasgouttes]

Post by Jürgen Spitzmüller
I haven't checked which kind of red JMarc used, but in connection to our
discussion today I'd say: use a color that is used to indicate that this is
related to the editor, not the LaTeX output.

I used a plain ugly red, but this is not supposed to be my last word on
it: It is more like a proof of concept.

Post by Jürgen Spitzmüller
The dark red used a.o. for indendation markers seems appropriate, doesn't it?

Well, actually I would propose to turn this depth bar into something
more subtle like maybe the same gray we use for pilcrow marks.

JMarc

PS: and get rid of the ugly blue line related to alternate languages.
Probably we can turn it into a dotted line with a less agressive blue.

[Jürgen Spitzmüller]

Well, actually I would propose to turn this depth bar into something more
subtle like maybe the same gray we use for pilcrow marks.

OK. Then use that for all "editor-related" marks.

JMarc
PS: and get rid of the ugly blue line related to alternate languages.
Probably we can turn it into a dotted line with a less agressive blue.

Personally, I have turned that into a pale green long time ago. I agree the
current marking is too brute.

JÃŒrgen

[Jim Oldfield]

Hi,



I'm a long-time user of LyX. I hope you don't mind me adding my feedback to this developer conversation, but I came across this issue recently when I changed my background colour from the default to sky blue, and found this needed a lot of settings to be changed. I also turned off different colours for different insets, as they distracted from the overall structure of my document. Perhaps the colour groups I used could be of some interest. It agrees with JMarc's suggestion to use the same colour for the depth bar and pilcrows.



Background: background, graphics background, greyedout inset background, math background



Background (darker): button background, frame of button, math macro background.



Background (darker still): button background under focus, selection.



Text: collapsable inset text, cursor, footnote label, greyedout inset label, math macro label, margin note label, note label math, math macro label, table line, table on/off line [it's dotted anyway], text, URL label.



Text (lighter): collapsable inset frame, depth bar, end-of-line marker, greyedout inset text, inline completion, math corners [see note below], math macro frame, new page, non-unique inline completion, page break / line break, paragraph marker, phantom inset text, special character,



Notes: comment background [doesn't exist but ought to], note background.



Highlighted frames: math frame, math line, preview frame



I think the first five could be deduced automatically by just setting a text colour and a background colour and interpolating. Enthusiastic users may disagree about some of these groupings, but most wouldn't care too much. The main exception is math corners (the ones that show all the time, not just when the cursor is there), which would benefit from an option to turn off like the paragraph marks; at the moment you can effectively turn them off by setting them to the background colour.



I'm sure there are many other colours that can be merged that I missed e.g. I don't know what a "command inset" is so didn't say anything about its colours.



Many thanks for all your hard work on LyX.



Jim



From: lyx-***@lists.lyx.org [mailto:lyx-***@lists.lyx.org] On Behalf Of JÃŒrgen SpitzmÃŒller
Sent: 29 July 2014 9:17 AM
To: Jean-Marc Lasgouttes
Cc: LyX-Devel
Subject: Re: Call for testers: the features/scroll-reloaded branch



2014-07-28 20:39 GMT+02:00 Jean-Marc Lasgouttes:

Well, actually I would propose to turn this depth bar into something more subtle like maybe the same gray we use for pilcrow marks.



OK. Then use that for all "editor-related" marks.




JMarc

PS: and get rid of the ugly blue line related to alternate languages. Probably we can turn it into a dotted line with a less agressive blue.



Personally, I have turned that into a pale green long time ago. I agree the current marking is too brute.

JÃŒrgen

[Jean-Marc Lasgouttes]

Post by Jim Oldfield
I'm a long-time user of LyX. I hope you don't mind me adding my feedback
to this developer conversation, but I came across this issue recently
when I changed my background colour from the default to sky blue, and
found this needed a lot of settings to be changed. I also turned off
different colours for different insets, as they distracted from the
overall structure of my document. Perhaps the colour groups I used could
be of some interest. It agrees with JMarc's suggestion to use the same
colour for the depth bar and pilcrows.

Hi Jim,

Thanks for sharing your ideas. This looks very thorough and well
thought. Do you have a screenshot to share with us?

My evil plan would be to reduce to something like 5 colors. Why have a
Tuturial where we tell people that 3 different typefaces is more than
enough and then scare them with all these colors (``Hmm, my inset is
new, it needs a new color. Hey look at this maroon, nobody used it yet,
that's a good choice!''). Unfortunately, I know that even mentioning
that leads to infinite discussions, and my time is to scarce for this
kind of fun.

This is why I had this plan of hiring some designer with leashes that
would just force a good solution down our collective throat ;) A bit
like the magnificent seven, but to or three guys should be enough.

JMarc

PS: command insets are the insets that only contain a button (bibTeX,
ref, label...)

Post by Jim Oldfield
Background: background, graphics background, greyedout inset background, math background
Background (darker): button background, frame of button, math macro background.
Background (darker still): button background under focus, selection.
Text: collapsable inset text, cursor, footnote label, greyedout inset
label, math macro label, margin note label, note label math, math macro
label, table line, table on/off line [it's dotted anyway], text, URL label.
Text (lighter): collapsable inset frame, depth bar, end-of-line marker,
greyedout inset text, inline completion, math corners [see note below],
math macro frame, new page, non-unique inline completion, page break /
line break, paragraph marker, phantom inset text, special character,
Notes: comment background [doesn't exist but ought to], note background.
Highlighted frames: math frame, math line, preview frame
I think the first five could be deduced automatically by just setting a
text colour and a background colour and interpolating. Enthusiastic
users may disagree about some of these groupings, but most wouldn't care
too much. The main exception is math corners (the ones that show all the
time, not just when the cursor is there), which would benefit from an
option to turn off like the paragraph marks; at the moment you can
effectively turn them off by setting them to the background colour.
I'm sure there are many other colours that can be merged that I missed
e.g. I don't know what a "command inset" is so didn't say anything about
its colours.
Many thanks for all your hard work on LyX.

[Jim Oldfield]

Sure. Here is an example screenshot of a real document with a couple of extra features added, both with my customised colours and the default ones. The new one looks a bit less impressive, but of course that's the point. In fact, it's not that big of a change overall.

I agree with everything you said. I am certainly not a designer (not that you were implying I am) so I won't be forcing anything down anyone's throats :-)

Let me add an extra note: Of course one change here is that there are fewer types of colours (especially for inset labels). The other is that the background colour has changed to blue. This change is a personal preference and I'm not proposing that it be the default. But the current default background colour of light sandy red is particularly unfortunate, because when something is red it’s not clear whether it’s really an error (e.g. ERT or spelling mistake) or just a darker version of the background colour (indentation bar, inset frame).

Again, thanks to everyone for all the hard work on LyX.

Jim

-----Original Message-----
From: lyx-***@lists.lyx.org [mailto:lyx-***@lists.lyx.org] On Behalf Of Jean-Marc Lasgouttes
Sent: 29 July 2014 1:43 PM
To: lyx-***@lists.lyx.org
Subject: Re: Call for testers: the features/scroll-reloaded branch

Post by Jim Oldfield
I'm a long-time user of LyX. I hope you don't mind me adding my
feedback to this developer conversation, but I came across this issue
recently when I changed my background colour from the default to sky
blue, and found this needed a lot of settings to be changed. I also
turned off different colours for different insets, as they distracted
from the overall structure of my document. Perhaps the colour groups I
used could be of some interest. It agrees with JMarc's suggestion to
use the same colour for the depth bar and pilcrows.

Hi Jim,

Thanks for sharing your ideas. This looks very thorough and well thought. Do you have a screenshot to share with us?

My evil plan would be to reduce to something like 5 colors. Why have a Tuturial where we tell people that 3 different typefaces is more than enough and then scare them with all these colors (``Hmm, my inset is new, it needs a new color. Hey look at this maroon, nobody used it yet, that's a good choice!''). Unfortunately, I know that even mentioning that leads to infinite discussions, and my time is to scarce for this kind of fun.

This is why I had this plan of hiring some designer with leashes that would just force a good solution down our collective throat ;) A bit like the magnificent seven, but to or three guys should be enough.

JMarc

PS: command insets are the insets that only contain a button (bibTeX, ref, label...)

Post by Jim Oldfield
Background: background, graphics background, greyedout inset
background, math background
Background (darker): button background, frame of button, math macro background.
Background (darker still): button background under focus, selection.
Text: collapsable inset text, cursor, footnote label, greyedout inset
label, math macro label, margin note label, note label math, math
macro label, table line, table on/off line [it's dotted anyway], text, URL label.
Text (lighter): collapsable inset frame, depth bar, end-of-line
marker, greyedout inset text, inline completion, math corners [see
note below], math macro frame, new page, non-unique inline completion,
page break / line break, paragraph marker, phantom inset text, special
character,
Notes: comment background [doesn't exist but ought to], note background.
Highlighted frames: math frame, math line, preview frame
I think the first five could be deduced automatically by just setting
a text colour and a background colour and interpolating. Enthusiastic
users may disagree about some of these groupings, but most wouldn't
care too much. The main exception is math corners (the ones that show
all the time, not just when the cursor is there), which would benefit
from an option to turn off like the paragraph marks; at the moment you
can effectively turn them off by setting them to the background colour.
I'm sure there are many other colours that can be merged that I missed
e.g. I don't know what a "command inset" is so didn't say anything
about its colours.
Many thanks for all your hard work on LyX.

[Cyrille Artho]

Post by Jim Oldfield
Sure. Here is an example screenshot of a real document with a couple of
extra features added, both with my customised colours and the default
ones. The new one looks a bit less impressive, but of course that's the
point. In fact, it's not that big of a change overall.
I agree with everything you said. I am certainly not a designer (not
that you were implying I am) so I won't be forcing anything down
anyone's throats :-)
Let me add an extra note: Of course one change here is that there are
fewer types of colours (especially for inset labels). The other is that
the background colour has changed to blue. This change is a personal
preference and I'm not proposing that it be the default. But the current
default background colour of light sandy red is particularly
unfortunate, because when something is red it’s not clear whether it’s
really an error (e.g. ERT or spelling mistake) or just a darker version
of the background colour (indentation bar, inset frame).
Again, thanks to everyone for all the hard work on LyX.
Jim

Hi Jim,
I like your screenshot (although I admit that I prefer a brighter
background color).
I think the small changes are the most important ones; in the original
color scheme, all text descriptions of insets have their own color (foot1,
Note, Greyedout, etc.). Your screenshot shows that this is clearly not
necessary and actually distracting.

That part we can of course change easily and immediately (if everyone
agrees): The label of an inset should be the default color (black).

The second important observation is that boxes should be dark grey instead
of colored. This way, red can stand out to mark something that should be
fixed. Again, we could adapt that fairly easily if we get an agreement.

[Jean-Marc Lasgouttes]

Post by Scott Kostyshak
Well, my thought was "anything but red". For me, red should be
reserved for something that we think is likely wrong (warning/error).
I think it is a cheap way to draw attention, kind of like how we add
exclamation points in many places. I prefer to save red and
exclamation points for where we really want to get the user's
attention, otherwise they will become desensitized.

I saw it as a warning that part of the text is not visible. And I indeed
wanted it to catch the eye (but a little bit only).

Post by Scott Kostyshak
I'm trying to think of analog concepts in other applications. In Libre
Office Calc, if you put a long string in one cell, and then in the
next cell to the write you put something (anything), in the first cell
a red arrow is shown.

This is more difficult to do, since the arrow would have to be in the
right sfont (in terms of size) and we do not have such information at
row level). I also though about a jagged line, but it would be even more
eye-catcher (and I'd have to code it :).

Post by Scott Kostyshak
Do you have UI guides/books that you would recommend for study? I
remember you referenced the Apple UI guide. Would you recommend that
one?

Windows (colors):
http://msdn.microsoft.com/fr-fr/library/windows/desktop/dn742482.aspx

Mac OS X (general):
https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/UEGuidelines/UEGuidelines.html#//apple_ref/doc/uid/TP40002720-TPXREF101

I have not read them, though.

JMarc

[Scott Kostyshak]

On Mon, Jul 28, 2014 at 10:13 AM, Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes
I saw it as a warning that part of the text is not visible. And I indeed
wanted it to catch the eye (but a little bit only).

I see.

Post by Jean-Marc Lasgouttes

Post by Scott Kostyshak
I'm trying to think of analog concepts in other applications. In Libre
Office Calc, if you put a long string in one cell, and then in the
next cell to the write you put something (anything), in the first cell
a red arrow is shown.

This is more difficult to do, since the arrow would have to be in the right
sfont (in terms of size) and we do not have such information at row level).
I also though about a jagged line, but it would be even more eye-catcher
(and I'd have to code it :).

I referenced the above not for the arrow but because the arrow is red,
which supports your implementation.

Post by Jean-Marc Lasgouttes

Post by Scott Kostyshak
Do you have UI guides/books that you would recommend for study? I
remember you referenced the Apple UI guide. Would you recommend that
one?

http://msdn.microsoft.com/fr-fr/library/windows/desktop/dn742482.aspx
https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/UEGuidelines/UEGuidelines.html#//apple_ref/doc/uid/TP40002720-TPXREF101

I will keep this in mind. Not sure I want to commit to reading yet,
but they will be good to have as references.

Scott