Re: RFC: Designing Logo of Pandoc

[BP Jonsson <bpjonsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 7360 bytes --]

TL;DR: I see no reason to require that a logo reflects aspects of the
project beyond the basic public interface, and absolutely no reason to make
a logo design unnecessarily complex for such a reason, because there
shouldn't be any pressure on users to get involved beyond the public
interface, except as and when they feel the need themselves.

I've been thinking a bit more about this and I wonder what kinds of
misunderstandings of the model you are thinking of. The closest thing I
have seen on this list and on StackExchange has been users getting bitten
by this or that feature of LaTeX or RestructuredText not being
representable in the current AST format. I wouldn't call that
misunderstanding of the model but rather ignorance of what structural
elements of supported markup formats *the current implementation of the
model* can or cannot represent. That's not even limitations of the model
but limitations of the current implementation which could be removed[^1] in
a future implementation. I would argue that if they were removed most users
would just say "phew, finally pandoc supports my favorite markup feature"
without caring about what changes in the implementation, let alone the
model, have made it possible. That is as it should be. Users should not be
required, prodded or even expected to understand the engineering behind an
application, only the public interface. What sets open source apart is that
users *may* explore, understand and get involved in the engineering, even
are invited to do so, but there should be no pressure to do so. Even those
who do get involved usually only do so as and when they are able and
willing to enhance their own use of the product, or for their own
gratification, and that's entirely as it should be. Myself I'm still a
total Haskell illiterate, confining my contributions, and hence also my
understanding, to filterland. I have gotten rather involved in Jakob's Perl
filter support project, but that's in the end also helping myself to write
filters in my preferred language. To be sure I have written some filters in
response to requests on this list, but naturally that has been as and when
I have had, or got, an interest in the functionality requested. Otherwise I
have only more or less successfully requested John or others to add
features I have needed. That may change some day but there are hundreds if
not thousands of users out there who don't even get to the level where I
am, and that's entirely legitimate.

[^1]: NB I'm saying "could", not "should", but I'm thinking that even
without extending the current set of AST elements some unsupported input
format constructs could optionally be turned into Div, Span or link
elements with certain attributes by the readers so that they could be
handled with filters or turned back into their original constructs by the
corresponding writers -- optionally, since those attributes containers
would clutter the markdown output. That's another discussion however!

/bpj

Den 16 dec 2016 00:55 skrev "BP Jonsson" <bpjonsson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

> You may see the ∀ in the middle as representing the ∀ST around which the
> conversion between different input and output formats revolves! :-)
>
> /bpj
>
> Den 2016-12-15 kl. 01:40, skrev Kolen Cheung:
>
>>
>>
>> On Wednesday, December 14, 2016 at 8:45:41 AM UTC-8, BP wrote:
>>
>> To a normal user (I.e. you aren’t a Pandoc contributor or filter author)
>> the AST is an implementation detail which you don’t interact with. The
>> normal user experience is pandoc -f markdown -t html`, i.e. you input a
>> document in one markup format and get (a file) in anotheir markup format
>> (possibly zipped together with sundry other files) as output, without any
>> intermediate file or files. There is no point in creating a false
>> impression that there always must be an intermediate file. In fact that
>> may
>> scare off potential normal users. To them the thing which sets pandoc
>> apart
>> from other light markup processors is that it supports conversion back and
>> forth between multiple markup formats, and the logo should emphasize that.
>> The logo needs to be intelligible and meaningful to the less geeky users
>> which hopefully are in majority.
>>
>> /bpj
>>
>> It certainly is another possible perspective. So let me illustrate more on
>> my perspective:
>>
>>    1.
>>
>>    There are countless examples of expectation from end-users (including
>>    me) that originated from the misunderstanding of what pandoc is and
>> what
>>    pandoc does. Rather than trying not to “scare off potential normal
>> users”
>>    (which is unlikely to happen from a logo alone, since they won’t
>> understand
>>    the nuance in it at first sight), may be we should set the expectation
>>    right as early as possible, so that they won’t be disappointed later
>> on,
>>    and will not waste time to use pandoc for the wrong task.
>>    2.
>>
>>    The logo having arrows pointing to a common element representing AST
>>    will not make a real difference on first sight. But it would be a great
>>    “entry point” to talk about the philosophy behind pandoc. Having a 2nd
>>    layer of sophistication means intelligible and meaningful to me. (i.e.
>> at
>>    first sight you get something, but there’s a deeper story behind it.)
>>    - To further illustrate on this point, at first glance, pandoc seems
>>       very similar to some other tool, e.g. MultiMarkdown. But as one
>> pushes the
>>       tools further, they will realize pandoc is much deeper than what it
>> seems
>>       like at first glance. So, if the logo can have layers of meaning, it
>>       represents pandoc better.
>>
>> I don’t mean it has to be done this way. I mean if there’s arrows, arrows
>> pointing to a common element is more correct and deeper, and doesn’t
>> really
>> scare off people (may actually attract the right people), and is a path
>> worth explore. But if no design makes this looks good and natural, we need
>> not to force it.
>> ​
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/pandoc-discuss/29dbdf52-294b-b6a9-b598-ea742b5d4afb%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/CAFC_yuRfJ_8rEtGqxJvnWudMKT%2Bpgm8Go_cqoQ9TMDcN%2BqnsBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 8856 bytes --]