> > When I first wrote this plugin many years ago, the code looked very
> > much like what Paul has posted.
> My strong aesthetic is for minimal code which does the one thing I
> require, where as yours is to be highly configurable and meet many
> different use-cases from different people.
>
> Both approaches have value and there is room in this world for both.
Indeed... in many cases, minimal code can achieve the desired effect,
and I was *not* suggesting that there is only one plugin needed for
all use-cases.
In fact, I'm all for "aesthetic, minimalist coding"... I really love
it when a powerful result can be achieved in just a few lines of
code. However, when that result does not meet the actual expectations
of the users, then functionality dictates, and coding aesthetics lose
out.
The "minimal code" in your plugin IS very attractively simple and
understandable, and *seems* to provide exactly what is being
"required" ("close open tiddlers before opening another") and, as I
said previously, my plugin code started out nearly identical to what
you wrote.
However, while that code did fulfill the basic *functional
specification*, the actual *user experience*, as reported by real-
world users in the field, showed that it was not sufficient, and that
additional code was necessary to achieve the results that people were
actually asking for.
For example.... here's a use-case that is very common and causes a
VERY bad **loss-of-data** outcome:
1) edit a tiddler
2) make changes (but don't finish editing yet!)
3) click any link in the page
4) tiddler being edited is closed (without warning) and changes from
(2) are DISCARDED WITHOUT WARNING!
In addition to avoiding data loss, ensuring that a tiddler open for
editing is not *automatically* closed -- and can even be left open
after confirmation, even while viewing another tiddler -- it makes it
MUCH easier to copy/paste content between tiddlers. Otherwise, you
would have to "open-edit-copy-cancel" on the first tiddler, followed
by "open-edit-paste-done" in the second tiddler... and if you need to
copy more than one piece of content between tiddlers, you have to
repeat the entire cycle again for each snippet you need to copy!
Another example.... the "scrolling problem"....
1) document has lots of tiddlers, so sidebar tabs display is very long
2) open a long tiddler (one that doesn't fit on a single screen)
3) read that tiddler (scrolling to the bottom as needed)
4) without scrolling back up to the top of page.... click any link in
the sidebar
5) current tiddler is closed, new tiddler is opened, but...
6) this does NOT cause the browser to scroll back and, while the new
tiddler IS displayed, it is SCROLLED OUT OF VIEW, and there is *NO*
visible tiddler until the user *manually* scrolls the page back to the
top
Another example... the browser's BACK/FORWARD buttons....
Most people who use 'one at a time' tiddler display are attempting to
recreate the familiar page-transition experience of a 'normal' web
site. Included in that experience is the expectation that the
browser's BACK/FORWARD buttons can be used to quickly navigate between
the visited 'pages' (i.e. tiddlers).
In fact, this particular expectation is reinforced by the plugin code
because the URL in the browser IS being updated to show the current
"#TiddlerName" permalink. However, while the brower's history does
include each permalinked URL, pressing the BACK/FORWARD buttons does
nothing, because there is no real page transition occuring even though
the URL in the browser *does* change.
Additional plugin code was needed to enable TiddlyWiki to detect and
respond to these browser-based events so that the *expected*
navigation behavior could be supported. While this code adds
complexity to the plugin, it is also 100% transparent to the user, and
things "just work" as expected.
Of course, the user *could* install something like
http://www.TiddlyTools.com/#BreadcrumbsPlugin
to provide an alternative means of navigating the tiddler "history"
for the current session. However, this approach is obviously MUCH
more radical than merely adding code to SinglePageModePlugin, and
still doesn't address the user's expectation that the brower's BACK/
FORWARD buttons *should* just work in this situation.
In conclusion: while I also prefer 'minimal' code when appropriate,
TiddlyWiki is not an exercise in software engineering principles..
it's a practical tool for helping real people to accomplish their
goals, and a 'solution' that does not meet those goals is not a
solution at all.
respectfully,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.
