Hi, Pe 19.11.2010 11:06, Anca Luca a scris: > > On 11/19/2010 08:44 AM, Marius Dumitru Florea wrote: >> On 11/18/2010 12:56 PM, Vincent Massol wrote: >>> On Nov 18, 2010, at 11:40 AM, Ecaterina Moraru (Valica) wrote: >>> >>>> On Wed, Nov 17, 2010 at 20:45, Vincent Massol<[email protected]> wrote: >>>> >>>>> Hi Caty, >>>>> >>>>> On Nov 17, 2010, at 5:39 PM, Ecaterina Moraru (Valica) wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> This is a proposal for compacting the way we show XWiki Syntaxes >>>>>> >>>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/SyntaxExperiments >>>>>> Feedback is welcomed. >>>>> It looks good. >>>>> >>>>> I have some questions: >>>>> >>>>> * I think it would be good to have a menu on the left listing all the >>>>> syntax "domains": text formatting, tables, sections, etc and when you >>>>> click >>>>> on "domains" you get the doc for that domain (without reloading the whole >>>>> page if possible) >>>>> >>>>> >>>> I think this feature is already covered by the TOC. >>> TOC is good but a nicer left menu is even better IMO. >>> I'd envision something similar to the left menu in the new admin UI you've >>> been working on. >>> Note that it's not a big point and it could be done as a second step later >>> on. >>> >>>> The main reasons I like it in the current form are: >>>> + the toc gives you a way to navigate to the desired section and this is >>>> accessible/visible since the beginning of the page. We could improve here >>>> by >>>> grouping into some categories (text editing, development, multimedia) and >>>> also using some numbers to show the hierarchy 1., 1.1, etc. (makes it much >>>> easier to follow the nesting) ; >>>> >>>> + if you want to browse the content, learn the syntax or just see XWiki >>>> syntax capabilities, is much easier to do this by scrolling than segmenting >>>> the content and needing to click each time. >>> Yes this is the part that I don't like too much. It makes the page look a >>> bit huge and messy. >>> >>> However we could have the best of both worlds with something like: >>> http://confluence.atlassian.com/renderer/notationhelp.action >> Nice. This also shows that we don't need 3 columns. The information >> given by the "Feature" columns (which takes a lot of space) can be >> integrated in the other columns or moved outside of the table in a >> section title. >> >> I don't like the syntax chooser but I don't have a better solution (that >> scales with the number/version of syntaxes). For each non-default syntax >> I have to click twice to be able to copy&paste the example in my page. > I agree. Also, it took me a while to understand how it works. I would > have expected to work like tabs and switch to the clicked syntax only. > At first it felt like random stuff being displayed, which I blamed on a > potential bug in the mocked interaction. > Also I wonder how does that scale... (if you have 7 syntaxes, it's gonna > be a lot of strikedthrough text). > > I wonder if the benefits of the inline comparison (which are those, > btw?) are bigger than the drawbacks of not understanding how it works > and the amount of clicks needed to get the code. > > WDYT? > > Anca > +1
I didn't understand immediately the current syntax. It took me a couple of minutes to figure it out. I believe this can be improved from a visual POV, however the issue of one too many clicks remains. I'd like to be able to view one syntax and after that click on another syntax (and see solely that) in order to copy content or even compare the different syntaxes. I find more value in spotting the differences by clicking on the syntaxes, rather than using the inline comparison, especially for big chunks of syntax & code. Taking into consideration making such a comparison implies going back and forth a few times, it can become annoying to select, select, deselect, select, deselect, select, deselect, etc. Thanks, Silvia >> Thanks, >> Marius >> >>> (check the ALL entry) >>> >>>> - the negative part about the current model is when you want to access two >>>> non-sequential categories: you either scroll until you find it, or go top >>>> and use another anchor. >>> Yes. >>> >>>> The generic solution for this problem (and this targets all pages, which is >>>> much nicer than building something custom just for the Syntax page) is the >>>> option to select to have a following TOC (the way we have now the page >>>> related action menu). >>> Or a panel on the left. >>> >>>>> * We need to ensure that this syntax help page is accessible for people >>>>> with deficiencies (ie it must pass WCAG) since some of them won't be able >>>>> to >>>>> use the WYSIWYG editor they'll need to use the wiki editor and thus know >>>>> how >>>>> to write in wiki syntax. How could we make the syntax chooser work nicely >>>>> for WCAG? >>>>> >>>> About WCAG: >>>> >>>> - the main problem with generated tables from wiki markup is that they lack >>>> summary attr. We can fix this by creating a macro that creates the table >>>> header, and we need one because the header will need to specify the >>>> syntaxes >>>> available for the specific feature (some features will be available just >>>> for >>>> syntax 2.0 and 2.1 for example). >>>> >>>> - we will improve the syntax chooser to conform with Link guidelines (will >>>> have underline, be marked as links and have title attr); >>>> >>>> - because of the ison feature between syntaxes, various syntax code is >>>> mixed. For people that use screen readers will have hidden markup that will >>>> mark each line, and also have final total code written (not visible for the >>>> others), Example: >>>> >>>> <dt>term2</dt> >>>> :; term2 >>>> <dd>definition2</dd> >>>> :: definition2 >>>> >>>> will be marked: >>>> >>>> [Syntax 1.0] >>>> <dt>term2</dt> >>>> <dd>definition2</dd> >>>> >>>> [Syntax 2.0] >>>> :; term2 >>>> :: definition2 >>>> >>>> [Comparison] >>>> [Syntax 1.0]<dt>term2</dt> >>>> [Syntax 2.0] :; term2 >>>> [Syntax 1.0]<dd>definition2</dd> >>>> [Syntax 2.0] :: definition2 >>>> >>>> Please tell me if there are other WCAG problems. I will improve the >>>> proposal to show the hidden markup. >>> ok thanks >>> -Vincent >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
