TW interface annoyances - what are yours?

[Amzg]

For core TW (and also to a great extent for MPTW):

Please note that most questions are just *rhetorical*.

* one is typically forced to scroll up after having edited a tiddler.
Ought to be some kind of "jump to top" at bottom of each tiddler,
particularly in edit view. Even a small tiddler template change such
as swapping places for the tiddler name and the menu actually makes a
surprisingly positive difference (I've edited my templates). It is
surprising how often I previously found myself forced to scroll a mere
centimeter to reach the menu.

* if I have a bunch of tiddlers and I'm focussed on the lowermost one,
and close this one... I get to watch the bottom of the new lowermost
tiddler or even a screen of nothing. Instead, default ought to put e.g
the lowermost tiddler into focus (including its tiddler title).

* I am the typical single TW user... and thus I typically go under the
name "YourName" in most of my TWs and tiddlers. Name specification
ought to be an optional feature. (This is btw particularly confusing
for server side implementations, such as tiddlyspot, that require a
username that may not be the same as whatever is in place of
YourName..)

* On a related note, when starting out with an empty TW, why can't I
just fill in the GettingStarted tiddler straight away instead of
having to open everything manually. Or, why can't I click, say, the
SiteTitle up there and edit it directly?
BTW, A newbie recently attempted to edit the very tiddler-name
"SiteTitle" into his desired site title. Actually makes sense.

* In sidebar, I frequently go into Timeline and All, but very rarely
into Tags.
On the other hand, under More... I go into Shadow quite often (but
only for a few specific tiddlers in there).

* Options slider is filled with blue links, attracting attention if
nothing else, but none of them exist... And the recurring word
TiddlyWiki is also a link that does not exist. I'd say 100% of us has
clicked it at one one early stage, only to become a tad confused.


What are your interface annoyances?


P.S The above is written to be constructive as opposed to negative. I
love TW.


/Mat

[bob]

I'm new so I don't feel competent to give a technical response. However
I do recognise some issues that pain me too and would like to add my
voice/learn the fix for it.

When I auto generate a bunch of tiddlers the focus goes to the bottom
one, I would like it to go to the top one please. A 'jump to top' of a
bunch of tiddlers, automatically applied when a group of tiddlers are
auto displayed, would be great!

[Eric Shulman]

> * one is typically forced to scroll up after having edited a tiddler.
> Ought to be some kind of "jump to top" at bottom of each tiddler,
> particularly in edit view.

The following can be added to your ViewTemplate (and/or EditTemplate):

<!-- "scroll to top of tiddler" button (direct inline HTML
scripting): -->
<!-- puts 'uparrow' (x25B2) button in lower right of tiddler -->
<div class='toolbar' style='line-height:100%;margin-top:.5em;'>
<a href="javascript:;"
onclick="window.scrollTo(0,ensureVisible(story.findContainingTiddler
(this)));return false;"
onmouseover="this.title='scroll to top of
'+story.findContainingTiddler(this).getAttribute('tiddler')">&#x25b2;</
a>
</div>
<div class='tagClear'></div>

You can see this in action on www.TiddlyTools.com

> * I am the typical single TW user... and thus I typically go under the
> name "YourName" in most of my TWs and tiddlers. Name specification
> ought to be an optional feature. (This is btw particularly confusing
> for server side implementations, such as tiddlyspot, that require a
> username that may not be the same as whatever is in place of
> YourName..)

Unless you have added TiddlyTools' SetUserNamePlugin, you aren't
actually forced to *set* the value of 'txtUserName' (which defaults to
"YourName")... of course, regardless of the value, when you edit a
tiddler, the current username is saved in the 'modifier' field of that
tiddler. However, there's not any actual need to *display* that
username when viewing the tiddler. Just modify the ViewTemplate
definition and remove this:
<span macro='view modifier link'></span>
so that the username is no longer shown.

> * On a related note, when starting out with an empty TW, why can't I
> just fill in the GettingStarted tiddler straight away instead of
> having to open everything manually.

[[GettingStarted]] just presents *instructions* for what to do... and
includes links to the individual tiddlers that are used to set the
title/subtitle.

> * In sidebar, I frequently go into Timeline and All, but very rarely
> into Tags.

While "Timeline" has obvious utility, the "All" tab is only really
useful when you know the title of the tiddler you want to view... and,
for that case, I use TiddlyTools' GotoPlugin, which lets me simply
type in a few characters to quickly match and select a tiddler title
from a droplist of all tiddlers in the document.

Also, the usefulness of the "Tags" tab depends entirely on how you are
using tags in your document... if there are lots of tiddlers with
different tags, the "Tags" tab can be indispensable, both for
navigation and tag management.

> On the other hand, under More... I go into Shadow quite often (but
> only for a few specific tiddlers in there).

The only time I use "Shadowed" is when I am initially customizing a
default definition. Once a custom version of a shadow tiddler is
created, it appears in the regular Timeline and All lists, so there's
really no need to go back to the Shadowed tab just to select that
tiddler. This is especially so if using the GotoPlugin noted above,
as it becomes trivial to just type a few letters to jump straight to
the desired tiddler.

> * Options slider is filled with blue links, attracting attention if
> nothing else, but none of them exist...

These tiddlers *do* exist on TiddlyWiki.com, and provide some basic
info about their corresponding options. However, while the default
[[SidebarOptions]] shadow tiddler contains references to these info
tiddlers, the info tiddlers themselves are not shadows, and thus are
not automatically present in an 'empty' TiddlyWiki starter document.

> And the recurring word
> TiddlyWiki is also a link that does not exist. I'd say 100% of us has
> clicked it at one one early stage, only to become a tad confused.

Same as above... though for this case, I think that adding a shadow
definition for [[TiddlyWiki]] might make some sense. This shadow
could contain a very short description (e.g., "TiddlyWiki is ..."),
followed by links to www.TiddlyWiki.com and www.TiddlyWiki.org.

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios

[altiplano]

About issue 1), I use Ctrl+Enter after editing and it brings me to the
top of the tiddler. I'm new to TW (using MPTW) and can't tell if it's
a basic feature or not.

I share your annoyance about issue 2) : focus on the top (=title) of
the new lowermost tiddler would be more user-friendly, as well as a
keyboard shortcut to jump to the previous/next tiddler beginning.

Issue 3) : single TW user too and only local use so far, so no related
problem encountered yet.
Issue 4) : I prefer to keep the Getting Started tiddler as is for any
future reference. I've just added TW and Tutorial tags to it. Maybe it
could include a "Click here to create your first own tiddler" mention.

Also one thing that is not an interface annoyance so to speak but an
aspect I find hard to explain :
the fact that the upper frame (which contains the TW title and
subtitle) holds around 15% of the screen height in most themes (when
half of it would be enough).
GTD TW theme is a notable exception.
Well I guess this depends on what you do with your TW.
And maybe I'm not into "read on screen" enough to realise this layout
is better for the eyes.

I'm less preoccupied with the TW screen width as I suppose it just has
to fit the nature and density of your tiddlers content, and your read-
on-screen preferences.
I may come to use different TW : one tight for explicit or low-
detailed stuff and one wide for unhaikuable things :-)

[Dave Gifford - http://www.giffmex.org/]

> * In sidebar, I frequently go into Timeline and All, but very rarely
> into Tags.
> On the other hand, under More... I go into Shadow quite often (but
> only for a few specific tiddlers in there).

This is an annoyance? Just be happy for all that functionality. I use
tags quite a bit now, though when I was a newbie I didn't use it at
all.

My annoyances with the original TW design are still the following:

1. Header is so stinking tall! What a bunch of vertical real estate
gets wasted on the header. Almost all my TW adaptations reduce that
quite a bit.
2. TW and most of the TW users tend to favor Arial font, which I find
unpleasant to read. All my stuff is switched to Verdana, and some of
my personal stuff is now in Calibri.
3. When you make change #2 you discover how incredibly narrow the
MainMenu is, so I had to widen it on mine.

Those are the only changes I would make to the standard interface. The
rest of the changes I make by default are things I don't think should
be part of the standard TW interface.

Dave

[Amzg]

Eric, thanks for your input. I was really not expecting actual help on
the matters, but I was delighted to get it. Particularly that little
"jump to top" in the templates is wonderful. Altho I can understand
such a thing may not be a core thingy, maybe an idea would be to put
it into some kind of "tweak package" that an average user probably
would typically appreciate. Just a thought.
BTW, is there any way to somehow put it into stylesheet or something
so that it won't be overwritten with updates (because it will be now,
right?)

As for;

> [[GettingStarted]] just presents *instructions* for what to do...

Yeah, that's exactly my point. And it would be more user friendly if
it was *not* merely instructions, but instead a type of form field
tiddler where things can actually be filled in directly instead, in
one place, or if things could be edited directly where they are - for
example, letting an empty TWs top field read <click here to set
title><click here to set subtitle> instead of the current "My
TiddlyWiki" and "a reusable..."
I dunno. But I do feel it is a bit annoying as it is,

Regarding your neat little GotoPlugin; would you say it can fully
replace your wonderful SearchOptionsPlugin that I'm currently using?
(A thought; maybe a combo would be beneficial? - i.e something that
behaves like GP with its narrow "popup slider" but with that current
bottom "Search for" feature resulting in that (kind of) top tiddler
that SO results in. The GP current floating search result are kind of
obscures things. While at it, a smallie; for GP, maybe a little [>]
type button next to the fill-in-field as one is now forced to mouse
down to click "Search" otherwise.)


Regaring;

> > * Options slider is filled with blue links, attracting attention if
> > nothing else, but none of them exist...

> > * TiddlyWiki is also a link that does not

I'm sure there are good "behind the scene explanations". I'm just
pointing out that they *are*, for me as a regular user, diverting my
attention. Not much, but a bit.


Again, thank you for all your input Mr.Shulman! I was kind of more
expecting it to turn into a thread of generally expressed preferences
and differences of opinion. Your help was of course a much betting
thing LOL.


/Mat

[Eric Shulman]

> Regarding your neat little GotoPlugin; would you say it can fully
> replace your wonderful SearchOptionsPlugin that I'm currently using?
> (A thought; maybe a combo would be beneficial? - i.e something that
> behaves like GP with its narrow "popup slider" but with that current
> bottom "Search for" feature resulting in that (kind of) top tiddler
> that SO results in. The GP current floating search result are kind of
> obscures things.

GotoPlugin doesn't actually do anything special to render the search
results... the 'search for text' entry in the GotoPlugin droplist
simply invokes a regular search action, just as if you had typed into
the search field. If you don't have SearchOptionsPlugin installed,
you get the standard TW default search behavior (i.e., immediately
display all matching tiddlers).

If you *do* have SearchOptionsPlugin installed, then the results are
rendered based on the settings in that plugin, including the option to
display the results in a list at the top of the story column. Thus,
you can install both GotoPlugin and SearchOptionsPlugin together to
get the effect you want.

Also, the 'floating' search results panel on TiddlyTools is not part
of either GotoPlugin or SearchOptionsPlugin. Rather, it is a custom
tweaked #searchPanel DIV that is explicitly-defined in the
PageTemplate so it can incorporate the <<moveablePanel>> macro to make
it float (see TiddlyTools' MoveablePanelPlugin and
PanelManagePlugin). Without this customization, the #searchPanel will
appear as a DIV at the top of the story column, as usual (assuming you
have enabled that option in SearchOptionsPlugin)

> While at it, a smallie; for GP, maybe a little [>]
> type button next to the fill-in-field as one is now forced to mouse
> down to click "Search" otherwise.)

If you enter text into the GotoPlugin input field and press ENTER, it
opens the specified tiddler (even if it doesn't exist). However, if
you press SHIFT-ENTER, it immediately invokes the 'search for text'
item, directly from the GotoPlugin input field.

[iain]

I wouldn't have posted except for reading Dave's comments - I like
larger Headers and Aerial font! Goes to show how annoyances are not
universally shared.

I think the saving issue is a big annoyance and if anyone goes through
this group and checks I think it might be the No 1 question.

I keep getting the "A script from "file://" is requesting enhanced
abilities that are UNSAFE and could be used to compromise your machine
or data:...etc" screen from Firefox which would be nice to dispense
with. not sure whether it is a TW problem of a Firefox one.

Also the options thing often doesn't save my name so next session I
have to enter it all again.

[Morris Gray]

I posted this on Christmas eve but I think it's worth repeating
often :-)

See http://firefoxprivileges.tiddlyspot.com/

There is also a bookmarklet you can drag to your Firefox
toolbar. The link is on the above site but you might not find it.
You can
easily set privileges for any of your TiddlyWikis

http://icanhaz.com/firefoxprivileges

Morris

[Matt L.]

I would say that having the default behavior save the config data to
the cookie is an annoyance. I wish the default value of TW and all
plugins was to save to the config tiddler - only those who choose to
use the cookie method should do that. It would make TW much more
portable out-of-the-box.

- Matt L.

[Morris Gray]

On Jan 14, 9:13 am, "Matt L." <swordsma...@gmail.com> wrote:
> I would say that having the default behavior save the config data to
> the cookie is an annoyance. I wish the default value of TW and all
> plugins was to save to the config tiddler - only those who choose to
> use the cookie method should do that. It would make TW much more
> portable out-of-the-box.

Hear hear! That is my number one annoyance!

Morris

[Eric Shulman]

> I would say that having the default behavior save the config data to
> the cookie is an annoyance.  I wish the default value of TW and all
> plugins was to save to the config tiddler - only those who choose to
> use the cookie method should do that.  It would make TW much more
> portable out-of-the-box.

Saving settings to a 'configuration tiddler' instead of cookies
produces a different semantic: instead of associating the settings
with a given user/browser, the settings will be tied to the document.
if you are creating private documents that you never share with
others, this doesn't make much difference.

However, if you are publishing your document, then you need to be very
careful that any tiddler-based settings don't contain 'secret' data
(such as passwords, private URLs, local paths, etc.). This is one
advantage of cookies: they are guaranteed never to be revealed to
others... while document-based settings would be immediately visible
and *applied* to everyone that accesses the published document.

In addition, document-based settings won't permit variations in
personal preferences that vary from user to user (such as enabling/
disabling animations, incremental searching, etc.), as well as
stateful information (like the open/closed condition of specific
sliders).

While these settings *can* always be changed during a session, without
cookies, those changes don't persist to the next session. This can be
especially problematic when setting the desired username (in the
Sidebar options). Without cookies, every time you reload the
document, the usename would revert to either the tiddler-based stored
value (if any) or the built-in default "YourName".

Nonetheless, despite these differences in semantics, there *are* quite
a few settings that might be reasonably handled using document-based
storage. As you noted, however, such stored is *not* part of the
standard TW distro... but it IS available as an optional component:

http://www.TiddlyTools.com/#CookieManagerPlugin
http://www.TiddlyTools.com/#CookieManagerPluginConfig
http://www.TiddlyTools.com/#CookieSaverPlugin
http://www.TiddlyTools.com/#CookieSaverPluginConfig

CookieManagerPlugin lets you review/set/delete individual cookie-based
TW settings, as well as "bake cookies" to generate a static
[[CookieJar]] tiddler containing a snapshot of those cookies (or "bake
options" to create a snapshot of *all* current option settings, even
if they don't have a corresponding cookie).

CookieSaverPlugin extends this handling to capture cookie-based
settings as they occur and automatically write them to the
[[CookieJar]].

[Matt L.]

Thanks for the info, Eric! I freely admit that I use TW strictly for
my own information store and thus did not even consider those who use
TW as a website or to share information with others. I guess that
(being selfish) I wish the default action was for TW to store settings
internally, and only write to cookies if that option is enabled. I
suppose I look at TW as being designed primarily as a portable data
application that just so happens to function as a website and/or
sharing tool - not the other way around. As a portable application,
saving to cookies makes TW much less portable, since each new computer
you take it to would use the default settings... In order for it to
be truly portable, you have to use a cookie plugin or carry your
browser around along with your TW file (which I do - but that isn't
the point!). I guess it is six-of-one/half-dozen-of-the-other - and
my preferences happen to lie with the "other"... :-)

I will check out the CookieSaver plugin, though - that sounds like it
would be quite useful.

Thanks again!
- Matt L.

> http://www.TiddlyTools.com/#CookieManagerPluginhttp://www.TiddlyTools.com/#CookieManagerPluginConfighttp://www.TiddlyTools.com/#CookieSaverPluginhttp://www.TiddlyTools.com/#CookieSaverPluginConfig

[Simon Baird]

Look, you're not being selfish. Cookies are a bad idea for config. CookieSaver is a kludge to get around this and make TW config a little more bearable. I dream of the day when you can configure a TW in a sane way.

More discussion on this topic here:
http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/6945f595e6917ce5

A patch here:
http://trac.tiddlywiki.org/ticket/756

--
simon...@gmail.com

[Eric Shulman]

> Cookies are a bad idea for config.

As I noted in my previous response, cookies definitely have their use:
they permit saving of 'configuration' values that should *not* be
stored within the document, such as sensitive *private* data (i.e,
passwords and unpublished URLs) as well as tracking transitory
statefulness of various page content (slider opened/closed, current
tab), which are also two kinds of information that are typically
applied on a user-specific basis, rather than a document-specific
basis.

> CookieSaver is a kludge to get around this and make TW config a little more
> bearable. I dream of the day when you can configure a TW in a sane way.

My understanding of the word "kludge" carries a very negative
connotation... specifically, that of being a seriously flawed design
with badly written code that should be avoided whenever possible.
Even if that was not your intent, seeing that word used in regard to
CookieSaverPlugin (or any of my work) definitely made me bristle a
bit.

In fact, I feel that CookieSaver's design delivers *exactly* what is
needed: a flexible syntax for associating specified values with named
settings that can be stored within a single tiddler, saved with the
document, and then automatically re-applied each time the document is
loaded into the browser.

One aspect of the CookieSaver design that makes things extremely
straightforward is that it writes simple javascript assignment
statements (e.g., variablename="value") into the [[CookieJar]], which
is tagged with 'systemConfig' so that it will be invoked at startup to
set the specified option values. This technique is precisely the same
as the current practice of manually creating a [[ConfigTweaks]]
tiddler to set 'hard-coded' persistent option values. The only
difference is that the [[CookieJar]] contents are automatically
maintained by a plugin, instead of being hand-written by the document
author.

In addition, the use of javascript in the [[CookieJar]] means that
groups of simple assignments can be wrapped in 'if' tests, such as:
(document.location.protocol=="http:")
or
(config.options.txtUserName=="Joe")
so that certain settings will only be applied when specific conditions
are met. You can even use the [[CookieJar]] to declare default values
for settings that can still be overridden by individual users, like
this:
if (config.options.txtSomeSetting===undefined)
config.options.txtSomeSetting="thisvalue";
When initially loaded, the setting will use "thisvalue"... but if
txtSomeSetting is later changed (and therefore stored as browser
cookie), the local cookie value will supersede the hard-coded value,
allowing both author-defined document-based defaults and user-specific
browser-based preferences to be remembered and applied when
appropriate.

Please note that an alternative syntax for document-based settings
*has* been proposed (see http://trac.tiddlywiki.org/ticket/756), and
would use a 'slice table' to define the name/value associations.
However, the design is not yet fully specified, and currently suggests
adding new special-purpose syntax to the slice name parsing in order
to indicate when various conditional criteria should be applied to
determine which settings are to be used.

I think that using javascript is a *far* superior design than creating
yet another set of obscure TW-specific 'magic codes' to write into a
slice table... and, in any case, whether javascript or slice table or
some other as yet undefined format, the settings will still need to be
written into a tiddler that is saved in the file in order to achieve
document-based persistence, so at least that part of the design is, in
my view, obvious and inescapable.

In summary:

Although you might quibble about the particular syntax that is written
to the CookieJar, I think that CookieSaverPlugin is not only *not a
kludge*, but is, in fact, a very robust solution that addresses a wide-
range of use cases by employing a well-established syntax that
supports very flexible customization using programmable criteria.

thoughts?

-e

[Morris Gray]

On Jan 14, 3:09 pm, "Simon Baird" <simon.ba...@gmail.com> wrote:

> Look, you're not being selfish. Cookies are a bad idea for config.
> CookieSaver is a kludge to get around this and make TW config a little more
> bearable. I dream of the day when you can configure a TW in a sane way.

Maybe kludge isn't the right word as Eric doesn't do kludges, rather
it's making do with what you have and trying to be loyal to the
TiddlyWiki core, such as it is, as much as possible. However it does
represent a lot of overhead for something better fixed in the core to
start with.

I suggested in one of the links Simon points to was a type of *.ini
file that does travel with a TiddlyWiki and is specific to only that
TiddlyWiki. I see that while a TiddlyWiki is made up of modules, a
TiddlyWiki itself can be considered as a module in yet a bigger
system. Therefore they must not interfere with one another in any
way.

I gazed at the core today with glazed eyes wondering if there was a
way add a suffix to the cookies to make them specific to each
TiddlyWiki. That would solve a lot of the problems, but possible
create more.

Scrolling through I realized how many cookies are used in plugins
which is another issue to consider for any changes since the core
cookies can actually be a smaller part of the whole picture.

Cookies are, after all, a browser tool and what we really want for
most things is an *.ini file that has served so many applications for
so long. How this translates to TiddlyWiki is a matter of semantics.
I do agree with Eric that more specialized TiddlyWiki code shouldn't
be created for this as it creates too much inbreeding and will
eventually lead to a cul de sac sooner or later.

If there exists as, Simon says, a patch that we can try then what
better experiments could we do than for some of us to actually try it
and let it evolve.

Notwithstanding all of the above; the question of the massive
investment in plugins must be faced. How will any changes affect them?

Morris

On Jan 14, 3:09 pm, "Simon Baird" <simon.ba...@gmail.com> wrote:
> Look, you're not being selfish. Cookies are a bad idea for config.
> CookieSaver is a kludge to get around this and make TW config a little more
> bearable. I dream of the day when you can configure a TW in a sane way.
>

> More discussion on this topic here:http://groups.google.com/group/TiddlyWikiDev/browse_thread/thread/694...

> >http://www.TiddlyTools.com/#CookieManagerPluginhttp://www.TiddlyTools...

>
> > > CookieManagerPlugin lets you review/set/delete individual cookie-based
> > > TW settings, as well as "bake cookies" to generate a static
> > > [[CookieJar]] tiddler containing a snapshot of those cookies (or "bake
> > > options" to create a snapshot of *all* current option settings, even
> > > if they don't have a corresponding cookie).
>
> > > CookieSaverPlugin extends this handling to capture cookie-based
> > > settings as they occur and automatically write them to the
> > > [[CookieJar]].
>
> > > enjoy,
> > > -e
> > > Eric Shulman
> > > TiddlyTools / ELS Design Studios
>
> --

> simon.ba...@gmail.com

[Simon Baird]

On Wed, Jan 14, 2009 at 4:02 PM, Eric Shulman <elsd...@gmail.com> wrote:

>  Cookies are a bad idea for config.

As I noted in my previous response, cookies definitely have their use...

Sure. Cookies are good for some things. They are a bad for config. 

> CookieSaver is a kludge to get around this and make TW config a little more
> bearable. I dream of the day when you can configure a TW in a sane way.

My understanding of the word "kludge" carries a very negative
connotation... specifically, that of being a seriously flawed design
with badly written code that should be avoided whenever possible.

I believe using cookies for config can be accurately described as flawed design. (It's well written code though.. :)

You've created a very capable and useful solution/workaround to the flawed design. I call it a kludge because the real solution is to address the flawed design.
 

In fact, I feel that CookieSaver's design delivers *exactly* what is
needed: 

[snipped stuff about how CookieSaver works]
 

...a very robust solution that addresses a wide-

range of use cases by employing a well-established syntax that
supports very flexible customization using programmable criteria.

I'm sure it's wonderful but lets make it so TW users don't have to deal with this complicated stuff just to have a sane way to turn on backups or autosave.

Simon.

--
simon...@gmail.com

[overett1]

Afraid mine's the word 'tiddler'. Don't mind it personally but getting
a bunch of lawyers to take it seriously's going to be interesting -
has raised quite a few smirks already. Am referring to 'articles'
wherever possible but gave up changing plugins due to need to redo
when you upgrade. Would be great to be able to choose your own word
for a tiddler and that then be used throughout the wiki, and by plugin
authors.

[Matt L.]

I second that idea...

[Eric Shulman]

> I'm sure it's wonderful but lets make it so TW users don't have to deal with
> this complicated stuff just to have a sane way to turn on backups or
> autosave.

Install CookieSaverPlugin means that you don't have to deal with *any*
complicated stuff if you don't want to. The CookieJar contents are
maintained automatically, so the users *never* need to know how it
works... that's the one of the main feature points of the plugin...
providing in-document persistent settings *without* requiring people
to hand-edit a configuration tiddler (or even know *how* to edit it!).

When an <<option chk...>> or <<option txt...>> input is changed,
there's *no* additional actions that the user needs to do... the
CookieJar is automatically updated behind the scenes. You could even
tag the CookieJar with 'excludeLists' so it was hidden from the
sidebar tabs and then the user wouldn't even know that such a tiddler
exists.

As far as they are concerned, the only difference is that they changed
a setting in the normal way and it was remembered in the document...
nothing else is required of them, except for the unavoidable need to
save the file at the end of the session to preserve the changed
settings (if 'autosave' isn't enabled, of course).

-e

[Ken Girard]

When introducing folks to TW I refer to tiddlers as 'Notes'. As in
"Open up a new note and start writing about...". It helps them get the
idea quickly.

But at the same time I've gotten a couple of folks to understand that
in the modern world silly names are the way to go. For example iPhone,
Google, Kindle, Razr, and Prius. These 'Brandings' make it easier for
something to stand out on the internet. Can you imagine searching the
internet for something called Notes or Shoebox? (A friend keeps all
his ideas on index cards in shoe boxes)

Ken Girard

[Eric Shulman]

> > >  Cookies are a bad idea for config.
> > As I noted in my previous response, cookies definitely have their use...
> Sure. Cookies are good for some things. They are a bad for config.

I'd really like to know why you are so adamantly opposed to cookies...

I've repeatedly explained why I think that cookies are appropriate
(even necessary) for *some* kinds of TW option settings (e.g., storing
sensitive private data, tracking transitory slider/tab states,
enabling/disabling browser-specific features, user vs. document
preferences, etc.)

However, you keep responding with a generic "cookies are bad for
config" refrain... but have yet to explain WHY you think that is so.
Please elaborate on the *reasoning* behind your position. Otherwise,
it's just an hollow statement that lacks persuasive impact and adds
very little to the discussion.

thanks,
-e

[Simon Baird]

On Thu, Jan 15, 2009 at 3:21 PM, Eric Shulman <elsd...@gmail.com> wrote:
>
> I'd really like to know why you are so adamantly opposed to cookies...
>

At the risk of repeating myself, here goes.. Imagine this:

A user downloads a TW puts it's on their thumb drive configures it to
their preference, lets say he switches on backups, autosave, and
switches off animation, sets a backup directory and a few other
things. He feels satisfied that his TW is setup just how he likes it.
Then...

a) His browser is configured to clear cookies on shutdown. The next
day he opens up his TW and all his config is lost...

b) He uses the TW on another computer. ... All config is lost...

c) He opens in another browser on the same computer... All config is lost...

Now the user is:
* perplexed
* confused
* reentering their preferences. (perhaps again and again if they are
slow to catch on the 'eccentricities' of the TW configuration system.
* annoyed
* swearing
* in danger of losing data since he might not realise that backups are
switched off..

And so on. That's why.

Now let me preempt the standard rebuttal..

"But what about two different users of the same TW? One of them likes
animations on and one likes animations off? That's why the config
should be stored in cookies..."

(I was going to go on but I got other things to do...)

Look I know that cookies make sense for some things. But lets make
sure the baby is okay before we start working on the bathwater. Or
something like that.. (The baby is not having your TW preferences
disappear. And the hammer is my..... never mind.. [1] ;).

Best wishes,

Simon.

[1] Dr Horrible joke...

--
simon...@gmail.com

[Eric Shulman]

> Afraid mine's the word 'tiddler'. Don't mind it personally but getting
> a bunch of lawyers to take it seriously's going to be interesting -
> has raised quite a few smirks already.

There *is* a certain amount of 'giggle factor' in the word "tiddler".
However, that might cultural or regional, rather than a universal
effect. For example, in the UK and some other countries, a "tiddler"
is a small fresh water fish (http://en.wikipedia.org/wiki/
Stickleback), and is also synonymous with the American slang
"toddler" (a 2-year old child).

I suspect that in the US, "tiddler" may be evoking juvenile reactions
in some people due to the prurient connotations associated with
similar-sounding slang words such as:
"Tiddly" => "titty" and "tiddler" => "diddle her"

One way to potentially help reduce this response is to properly 'spin'
the name when introducing TiddlyWiki for the first time.

For example, you can explain to people that, although the combined
name "TiddlyWiki" might seem frivolous or even salacious, "Tiddly" is
simply a colloquial term that means "small" (like "TiddlyWinks"), and
"Wiki" is borrowed from the Hawaiian language word for "quick".

Thus, when you see "TiddlyWiki", think "small and quick"... and when
you see "tiddler" think "small piece of information" (aka "micro-
content").

After being suitably primed with this explanation, present your
audience with the following list of site names:
Google, Yahoo, YouTube, Flickr, NetFlix, FaceBook
and these made-up/borrowed words or unpronouncable acronyms:
iPod, blog, wiki, HTTP, PDF, SMS, MP3, DVD

Then, point out that, while a particular name might slow acceptance by
some people, it also seems that silly names have, in recent years,
been associated with some wildly successful products or services. In
fact, if the technology is really good, then the name won't hurt it
and may even help differentiate an entirely new category of software
(e.g., 'wiki', 'blog').

-e

[Eric Shulman]

> Look I know that cookies make sense for some things. But lets make
> sure the baby is okay before we start working on the bathwater. Or
> something like that.. (The baby is not having your TW preferences
> disappear.

That's exactly the problem that CookieSaverPlugin was built to
solve... it provides an alternative to browser-based cookies that
ensures that all TW preferences are automatically saved in the
document, so that they don't 'disappear' when you move between
browsers or systems (or flush the cookies).

In addition, the plugin can be configured to actually block use of
selected browser-based cookies (or set the browser itself to block all
cookies) while still having full access and use of all TiddlyWiki
option settings.

Perhaps if I had simply named it "OptionSaverPlugin" it wouldn't be
triggering your distaste for cookies.

-e

[Simon Baird]

On Thu, Jan 15, 2009 at 5:04 PM, Eric Shulman <elsd...@gmail.com> wrote:

> Look I know that cookies make sense for some things. But lets make
> sure the baby is okay before we start working on the bathwater. Or
> something like that.. (The baby is not having your TW preferences
> disappear.

That's exactly the problem that CookieSaverPlugin was built to
solve... it provides an alternative to browser-based cookies that
ensures that all TW preferences are automatically saved in the
document, so that they don't 'disappear' when you move between
browsers or systems (or flush the cookies).

Yeah, I think we're misunderstanding each other. Your plugin is great. It solves the problems. But I wish those problems weren't there to begin with.

--
simon...@gmail.com

[Eric Shulman]

> Yeah, I think we're misunderstanding each other. Your plugin is great. It
> solves the problems. But I wish those problems weren't there to begin with.

Agreed! Yay! :-)

[Eric Shulman]

> switches off animation

at the risk of seeming to flog the proverbial dead horse...

Consider the <<option chkAnimate>> setting. Suppose I have a Windows
system with both IE and Firefox. Let's also suppose that IE is slow,
and doesn't always display the animations smoothly and can even make
the document nearly unusable in some situations. Turning off
chkAnimate for IE helps alot. However... I normally use Firefox
rather than IE, and Firefox is much faster, so I don't want to turn
off the animation effects there. I want different values for the same
setting, based on which browser I am using.

Similarly, consider chkBackupFolder. Suppose I view the same document
on two systems, one at work, and the other at home. Both use the same
software (OS, browser, etc.). However, when I'm at work, the TW
document is on a shared network server, but when I'm home, it's just
in a local folder (or even kept on the thumb drive). Different
systems = different directory structures = different value for
chkBackupFolder.

Thus, the desired values for chkAnimate and chkBackupFolder depends
upon the *environment* in which I am currently operating, rather than
being specific to a given user or document.

In contrast, consider the chkIncrementalSearch option. This is more
of a *user-specific* setting. If I prefer to disable incremental
searching, I'd like that behavior to be applied, regardless of the
platform I am currently using, to every TW document I view... even if
that document was written by someone else and then published online
for read-only viewing.

Of course, there are also options, such as chkHttpReadOnly, that
clearly are intended be *document-specific*. For example, the author
of a document may want to be able to edit the document when posted
online, so they "hard-code"
config.options.chkHttpReadOnly=true;
into a [[ConfigTweaks]] (or [[CookieJar]]) tiddler, tagged with
'systemConfig'. This setting is then applied whenever that document
is loaded, regardless of where it is viewed or who is viewing it.

Thus, there are really three different types of settings:

* environmental
* user-specific
* document-specific

Environmental settings can use browser-cookies. Document-specific
settings can use a hand-written [[ConfigTweaks]] tiddler or a
[[CookieJar]] tiddler generated by CookieSaverPlugin. The "missing
link" is support for *user-specific* settings.

Perhaps something like the external "prefs.js" file used by FireFox
would fit the bill. The file would have to be portable and cross-
browser compatible, and could probably be auto-generated by TW in
response to a click on a command link (or whenever the current
document is saved).

thoughts?
-e

[Ken Girard]

I like the prefs file idea.
Something I've done on a couple of TWs is putting the options for
autosave, backups, location & animation in the SideBarOptions tiddler
so that they are visible.

Having autosave be an easy on/off is a mild concern of mine as
flashdrives can only take so much saving, and when you are playing
with CSS sometimes you can make a lot of tweaks before you get exactly
what you want. Why save it till it is correct?

Something I've thought about: I use the AlternateBackupPlugin (http://
no-sin.com/wiki/WorkTracker.html#AlternateBackupPlugin) which saves
sequental copies from 1-X (default is 10). I normally leave it on so I
have 11 copies of my TW in it's folder. Then once a week or so, I do a
copy/paste of the real TW and rename it to 'backup.twname.
0yy0mm0dd.html'. What would be great is a way to override the
AlternateBackupPlugin and use the standard backup without having to
disable, refresh, backup, re-enable, refresh.

Ken Girard

[Dave Gifford - http://www.giffmex.org/]

I proclaim this thread completely derailed...

Dave

[Ken Girard]

Forked even.
Whether that is forked as in split, or forked as in "Stick a fork in
me I'm done." I'm not sure.

Ken Girard

On Jan 15, 8:08 pm, "Dave Gifford - http://www.giffmex.org/"

[FND]

> I proclaim this thread completely derailed...

I've started collecting the issues raised here on the community wiki:
http://www.tiddlywiki.org/wiki/Dev:UI_Issues

That list is very selective; I've only added issues that are related to
the user interface and which I think are generic enough to be addressed
in the TiddlyWiki core.
(In order for these issues to be addressed though, they should be
discussed in separate threads on the developers list.)

Having said that, it's a wiki, so feel free to edit that page.

-- F.