aristotle pagaltzis said:> we can agree he has achieved more in three months
> than you have in a decade of talking.
i'm not sure who your "we" is, aristotle, but i guess this means
that you will not be doing alpha-testing for my new program...
how will i ever be able to manage without your valuable input?
***
but hey, maybe i'm wrong, and this list _has_ accomplished
something worthwhile and notable in the last three years...
if you believe it has, do please feel free to tell us what it was.
***
on the other side of the fence, however, i see lots and lots of
people who are doing things with markdown these days, but
only a very precious few even bother to come here and _tell_
this list what they are doing (and usually well after the fact),
and nobody -- and i mean absolutely nobody -- comes here
for _advice_ or "accumulated wisdom" or _anything_ like that.
heck, even _gruber_ doesn't bother to come here any more...
doesn't that make any of you people _wonder_?
***
emmanuel said:> I made a Markdown editor webapp two weeks ago:
> http://akaya.me ("Yet Another Markdown Editor")
you've made a nice start, emmanuel, a nice start indeed.
here is my review of "the good, the bad, and the ugly"...
***
we'll start with the "good" section...
as far as the "good" goes, i like that you've made a web-app.
it's time to put the script-kiddies to bed; if installing a script
is part of your workflow, the general public will never buy it...
and the way your app is taking care of "file management" is
in tune with how the trend seems to be heading these days...
moreover, the "yet another" name shows that you realize that
what you've done might be one in a big number of contenders;
it's good to have healthy expectations even if you dream big...
finally, you've made an improvement in the achilles' heel of
_every_other_ on-the-fly converter, as far as i know, which is
that they don't show the point which is being actively edited.
except for this last point, all of the items in your "good" list
are mirror-imaged in the "bad" category, which is _curious_...
***
so here's the "bad" section...
first, the web-app part. it is _good_ to have a web-app, but
it would be better if you had a combination of offline/online.
i understand the benefits of having something in the browser.
but native apps still have advantages, and likely always will...
the only approach i see prevailing long-term will _use_both_.
on "file management", i guess i'm old-fashioned, but i want to
know where the file is, be able to do direct manipulation on it,
edit it in another app, run my own spellcheck tools on it, etc.
i see where i can "download" the markdown file, but that would
then just be a copy of the actual "file", not the document itself.
i'm also unclear on where the actual "file" resides. is it in
the
offline cache for that specific browser? -- in which case even
another browser on my own machine won't be able to get to it?
as there's no log-in, it can't be stored "in the cloud",
meaning
that i certainly cannot get to it while using another _machine_,
thus removing a lot of the functionality of having a web-app...
confusions like these are gonna lose the average user quickly.
this brings us to the thing about having lots of "competitors"...
i fully realize you might just be doing this project "for fun" and
not have aspirations of making it "big"... but, at the same time,
you obviously know that a developer must do serious polishing
in order to take any project public in the way that you are doing.
having a base of users is what can make all that work worthwhile.
so you need to ask questions about what could make users come
to prefer your site over all of the other competing sites instead...
i don't have any answers; just telling you those are the questions.
as far as those "competitors" go these days, in my eyes you have
_two_ in particular that you'll need to stack yourself up against...
and no, google docs isn't one of them. :+)
(people looking for a web-based editor should most certainly
consider google docs. and they will do so, i am quite sure, but
if google docs makes 'em happy, no peons like us can compete.
we're splitting whatever scraps might fall off the google table,
as well as people who refuse to eat at that table on principle.)
and no, i don't consider all the other online-editing sites now
cropping up to be "your competition" either. on the one hand,
yes, of course they are. on the other hand, they are equivalent
to you, so there's no real good reason to prefer them over you.
not at the present time, anyway...
i feel much the same about all the ipad editing apps. they show
great promise, and the might be competitors to you long-term,
but for the here-and-now, they'll still have to prove themselves.
so as far as i can see, your competition is "marked.app" and the
still-forthcoming-but-any-day-now "multimarkdown composer".
and yeah, both of those are offline entities, so you might think
that they can't compete, by definition. but i'd say you're wrong.
first of all, let's grant that they are both _very_powerful_, in the
exact manner that we can expect offline applications to shine.
"marked" already has tons of fans, and the beta of
"composer"
was more than enough to show the promise of _that_ program.
so they've already got the offline part of the equation down pat.
with dropbox and all the other cloud-sync tools available now,
every document can have the capability of being omni-present.
so that aspect of the web-app is increasingly being matched up.
it'd be good (for them, bad for you) if "marked" and
"composer"
had online equivalents, but i don't think they're going to suffer
very much because of a lack of them. one beauty of plain-text
is that you can work with it in any text-editor, and that is one of
the assets "marked" -- in particular -- uses to great advantage.
so i think, even now, "marked" and "composer" have _enough_
of a combination of offline/online power that they can succeed
over and above an approach that uses an online-only strategy...
but that's my opinion, and i could be wrong, so if you disagree
with it, and you are willing to bet on yourself, go right ahead...
finally, we have your innovation -- showing the particular part
actually being actively edited by the person at the current time.
it was good of you to recognize this obvious flaw in many (all?)
the current on-the-fly converters, and you found the answer...
first, though, let's do a quick review.
most of the "dingus-style" online converters -- up until lately --
have been severely limited, in that they don't accept much text.
although i wouldn't expect that it would be "difficult" to mount
one of the converter-scripts so that it would handle large files
(where, by "large", i mean a text-file in the range of 250k-750k,
which is the amount of disk-space required by a "typical" book),
as far as i know (please correct me if i'm wrong), _no_one_has_.
so i was pleasantly surprised to see that your site took a big file.
(the browser gave the "this script is taking a long time" message,
but i clicked "continue" and it completed successfully, so there.)
all the online converters show the .html starting at _the_top_,
which is not what you want when you doing mid-doc editing,
and this is the improvement which you brought, emmanuel...
"marked" recently added the ability to "anchor" the display
to
the _bottom_ of the file, which is nice if you are adding text...
but if -- like me -- most of your writing is _rewriting_, then
most of the time you're working in the middle of a document.
and if you need to _scroll_ to see your "on-the-fly" preview,
it's really not all that "on-the-fly", if you know what i mean...
so emmanuel... your achievement here is truly a worthy one.
(which, for the record, is not to say the solution was difficult.
i worked it out for my program. it does get a bit problematic
when -- like "marked" -- you can't track the insertion point;
but even then, the secret isn't that hard to figure out, so i am
somewhat surprised that brett has not puzzled it out already.
he'd simply have to save each version of the text in a variable,
then compare it to the text the next time it is to be converted;
the first point of difference is where he should focus display.)
the "bad" part, emmanuel, is that your "preview" window is
tiny.
it needs to be bigger. much bigger. i like a display that splits
the full browser window into an "edit" half and a "display"
half.
now maybe that's just me, but i suspect that everyone will need
a preview window that's bigger than four or five lines of text...
***
and now we go on to finish up with the "ugly" section...
emmanuel, you might or might not know this, but one reason
that i say that this list hasn't "accomplished" anything in years
is that there has been a major problem confronting markdown
in that timeframe, and none of the responsible parties worked
to solve it. oh, they would "discuss" it every once in a while, but
the discussion would fade to silence, and nothing ever got done.
the problem is that there are many different markdown variants.
these variants all handle the main simple stuff of markdown in
the same way, because that main simple stuff is... well... simple.
but they are "variants" because they all have their own wrinkles.
none of them are consistent with each other, in the fine details,
not in a dependable way, so it's impossible for them to "share".
it _seems_ like "it works", because the main simple stuff works;
but if you use a variant-specific capability, it'll explode on you.
it's very much like the inconsistencies of "the browser wars"...
you have inadvertently stepped into the middle of this "war",
without even knowing it, because it is impossible to avoid it.
when you chose the converter from "stack overflow", you made
a declaration of allegiance to that particular markdown variant.
and now any text that a user creates in your system might give
_inconsistent_results_ if the user takes it to some other variant.
and they probably will not even _notice_ this inconsistent glitch,
since they won't have felt a need to scrutinize every little thing...
so they will put their product out in the world with a glitch in it.
not the end of the world, no sir. but not what they want, either.
how you choose to react to this ugly situation is your choice...
but perhaps the choice is more clear now than it might've been
-- oh, let's say -- six months ago. because the logjam on the
"variant" problem certainly looks to me like it's going to
clear...
up until now, each of the variants was roughly equivalent to
all of the other variants. thus none of them had an incentive
to "back down" from the overall competition to "be the
winner".
they could each hope that the other variants would choose to
"become compatible with the way i have decided to do things".
but "marked" and "composer" have upset that delicate
balance.
in case you don't know, "marked" defaults to multimarkdown.
and yes, "multimarkdown composer" uses multimarkdown too,
so multimarkdown has surged into the lead, and that lead will
take a sharp hike upward when "composer" gets released soon.
if "composer" is allowed to retain the "first mover"
advantage
for any length of time, the lead will become insurmountable...
so -- for the first time since markdown was first introduced --
we will all be able to count on a de facto markdown "standard".
will all of the variants -- including the stack-overflow one --
continue to exist? probably. but outside of their own venue,
they'll be largely ignored. if you can't edit a file in
"composer",
and have it act correctly, it won't be considered as "markdown".
and if it doesn't look right in "marked", it won't be
"markdown".
***
as i said, i have programmed an editor with on-the-fly display
for my light-markup system -- zen markup language, z.m.l. --
and a while back, i asked a question on this list about _which_
markdown variant i should use if i were to program a routine
in my editing-program that would convert z.m.l. to markdown.
today, i wouldn't bother to even ask that question any more,
because the answer is very clear to me -- multimarkdown...
unless one of the other variants makes a _big_move_ very soon,
multimarkdown will be the winner within a year, at the longest.
so if i were you, emmanuel, i'd use multimarkdown instead...
-bowerbird
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://six.pairlist.net/pipermail/markdown-discuss/attachments/20111016/d74c85e4/attachment.htm>