Open ds300 opened 10 years ago
h0ru5
commented
10 years ago I really like the way it is done now for parenthesis and double quotes. Its very unobtrusive, yet it clarifies the semantics. I would recommend this also for headings.
To take out anything non-text seems to be a common task for screen readers, since the official aria-attributes are very seldom. Maybe the accessibility topic offers some more pointers here?
peteruithoven
commented
10 years ago 5. Please don't change how you handle 5. I really think it works great.
6. I agree, but with a unordered lists, how would you know the difference between a next word and next bullet item? You won't know which bullet you're at / you can't count them.
7. A difference in heading style (size / color) etc can be hard to remember, with a word by word system you can't visually compare them. And having to adjust to a different style might be difficult. So I would prefer finding a wrapper.
Header 1:
Header 2:
Header 3 and below:
Header 4 and below:
I agree that pausing longer the higher the heading would be nice.
8 I agree with the color and icon, I would also underline it and make it clickable. (and when someone clicks; pause jetzt somehow. We could display the href underneath the reader? We could also listen to the enter key to "click" the link. If would not add all the links around the reader, that could make it very busy, especially on wikipedia for example.
9 We could actually display an image "in the reader" with a bigger delay?
For things like code and having context altogether it might be nice to highlight the word/element in the website. Then when the reader is closed the user knows where he was. We could even scroll the page to the highlighted word. I'm a bit unsure about doing this while you're reading because this might be distracting. We could improve the pause feature with this, we could move the reader to the top, highlight the current word and scroll there. And when you continue (press space) the reader goes back to the center and continues.
peteruithoven
commented
10 years ago Other headings idea:
Anahkiasen
commented
10 years ago Yeah more for colors and/or borders. The actual hX doesn't really serve any purpose because on higher speed you'll see it flashing by.
peteruithoven
commented
10 years ago If we can agree on a style for the headers I'd be happy to supply the css.
h0ru5
commented
10 years ago problem right now is that they are expected currently as 1-Char symmetric. So the way its currently done is causing a "jumping" of the text (see f2151a37e0cb1e4b92fc48c3bc40874c591a925c on dev branch). so we probably need some tweaking in the presentation code so that the parser can annotate the tokens as needed
peteruithoven
commented
10 years ago @h0ru5, you mean that the left wrapper character should have the same width so that the reader doesn't jump? We could give the wrappers a fixed width through css. I think we should add appropriate classes to the reader for example "header", "header1", "header2", "link", etc. Then we could add width descriptions in css. And if needed a bigger width for "header" for example.
ds300
commented
10 years ago The wrap stuff is fixed now. They can be unbalanced and of any length. see 09264fc755a21514df28f5f12cac7a2a91c49336
h0ru5
commented
10 years ago I can put those "hx" back in, but for the display as in the images, the wraps should also be assigned a style.
Maybe a class equal to the wrapper, e.g. sr-wrapper-h1 gets assigned whenever a h1 is displayed?
this would minimize code changes and would still enable experimenting with the options discussed above...
what do you think?
peteruithoven
commented
10 years ago Why add classes to each specific part when you can just add them to the .sr-reader div? You can just add classes like header, h1, h2, link etc etc
h0ru5
commented
10 years ago true. (the actual names should be prefixed or something to avoid naming collisions).
Actually, would it maybe be easier if those classes add the wrappings Such as " ( ) " etc? Then an instructions would just add or remove classes and all the skinning could be done in css, right?
ds300
commented
10 years ago @h0ru5 That sounds like a good idea.
ds300
commented
10 years ago on second thoughts, it wouldn't work for numbered lists unless we create a CSS class for all integers > 0 (which might make jetzt.css quite big)
j6k4m8
commented
10 years ago Possible suggestion: Numbered lists are mapped at parse-time to a range of colors, a la the Black-to-White mapping of H1-H4 illustrated above. So for a three-element <ul>, the first element is red, the second is orange, the third is yellow. For a ten-element list, the first element is red, the second is red-orange, the third is orange, and so on, so that even as the words flash by you can identify them by color association (which uses a different part of the brain than word-recognition, so we don't have to "multithread" our Wernicke's Areas).
Perhaps having the entire background change to a pastel-ized version of the color would be even more desirable, as you don't have to look to the side to see the identifying content.
I want jeztz to be able to succinctly and intuitively display the following types of text:
1-4 are simple and obvious.
5 could be done by some combination of the following:
I think 6 could be done nicely by putting the bullets/numbers in the left wrap section.
7 is tricky because there are different levels of heading. Even if there weren't, choosing a way to represent a heading is not obvious. Possible options are:
Of course whatever is done would have to be accompanied by appropriate pausing.
I think I have a decent solution for 8:
As far as I'm concerned, code blocks, images, tables, etc, make no sense for jetzt. However, it might be nice to deal with them in a similar way to hyperlinks.
Thoughts?