← Back to team overview

zim-wiki team mailing list archive

Re: Call for user cases ?


On Sun, Mar 4, 2012 at 00:49, Christoph Zwerschke <cito@xxxxxxxxx> wrote:
> Am 03.03.2012 18:41, schrieb Dotan Cohen:
>> And why would casual users know this?
> Well, to be honest I don't think zim is intended for "casual" users and
> never will because it is not intended to be a "wysiwyg" editor. People who
> want that wysiwyg stlye should use applications like OneNote or Evernote or
> MyBase or MyInfo or MyNotesKeeper. The special thing about zim is that it
> knows wiki syntax, and knowing the basics of that syntax is simply required
> to use it. It's explained very well in the online help. The other special
> thing about zim is that edit and view mode are not separated. People who
> want that separation of modes should use applications like ConnectedText or
> WikidPad or RedNoteBook.

If this is the case than that should be made clear. As it is, Zim
cannot handle arbitrary input and users are not likely to expect that.

Also, you might like to note that there is an Edit Source function in
the Tools menu. That is the place where one should be entering data in
raw format, not in the standard main window. A possible improvement
would be to have the Edit Source function edit the source in the Zim
window, with the cursor placed right where it was when in the standard
mode. Text entered in the standard mode should be automatically
escaped by Zim when converted to Source. That would solve all the
mentioned issues. I will write an RFE for this, give me a few minutes.

> The fact that I don't need to switch between edit and view mode is what
> makes zim so unique, and that paradigm really should be kept. For instance,
> if you see a mistake or type on a page, you simply go and correct it. You
> don't need to switch to an edit mode, search for the place with the error
> there, fix it, and switch back to view mode.

That could still be possible with the suggestion that I made above.
Thanks. I do agree with this benefit of Zim as you mention.

> But of course, this paradigm also has some disadvantages like the one you
> mention. I'm sure a lot can and will be done to attenuate these and make the
> tool even more usable. But you need to understand that they are somewhat
> inherent to the edit/view paradigm zim is using.
> One thing that surely should be added is a way to easily switch the editor
> to "raw mode" where it does not do any rendering. It should not be
> understood or used as the default edit mode, but it may be sometimes useful
> to see or edit the raw version of a page.

See the aforementioned Edit Source mode.

>> I see. Although I agree with your assessment that the data could be
>> recovered, it is still lost for Zim users. You and I might be able
>> to open the source file and retrieve the data. I would not expect
>> that of the casual user. That is quite the reason that I think that
>> it is a bit early to promote Zim to the casual user.
> See above regarding "casual users". A raw editing mode could help, but even
> that might not be found or understood by a casual user. Just like copying
> the data with "Copy as... -> Wiki" to get the raw data.
>> How about Python code, which maycontain triple quotes? Zim itself is
>> written in Python.
> But zim's triple quotes must be on a line for themselves, which rarely
> happens in Python snippets, and you can always indent your Python snippets
> to guarantee no triple quotes are at the beginning of a line. Also, Python
> normally uses triple double quotes for docstrings, not single quotes. So in
> reality, it's not much of an issue.

Python code was just an example. How about ASCII art? The fact is that
Zim should handle arbitrary input. Any argument to the contrary means
that Zim will be inappropriate for some use case or another.

Dotan Cohen


Follow ups